Conversation
| } | ||
| } | ||
|
|
||
| func TestWorkflowTestSuite_WorkflowRunOperation_ScheduleToStartTimeout(t *testing.T) { |
There was a problem hiding this comment.
Once the server support is merged can we make a CLI RC release to test against?
There was a problem hiding this comment.
We don't have tests for any timeouts with the server. I can add those if we want but IMHO it's enough to have the test env coverage because it means the command is properly generated SDK side and the server has functional tests using the gRPC API.
There was a problem hiding this comment.
I think we need to be able to assert the same behavior that a user can assert at runtime. This is a primary reason for integration tests in SDK, to confirm the runtime behavior as users see it is as expected. If a user can't even use this feature, there is no reason to merge/release it yet.
There was a problem hiding this comment.
Users will be able to use this feature in cloud, I will cut a new CLI RC so we can test and users can use in local dev.
There was a problem hiding this comment.
👍 Using in cloud has never been enough for an open-source SDK feature like this, but a CLI RC anyone (including our tests) can use works. Standalone activities will also benefit from this RC release.
|
For activity timeouts we expose the timeouts to the callee in the |
The handler will get the calculated operation timeout header today, which is set to We could consider making a more structured field to represent the operation timeout. |
3 participants
Overview
Implements two new granular timeout types for Nexus operations, allowing callers to have fine-grained control over different phases of operation execution:
These timeouts complement the existing Schedule-to-Close Timeout to provide better control and diagnostics for Nexus operation execution.
See also temporalio/api#695 and the corresponding server PR: temporalio/temporal#9010.
Do not merge until the API has been released.