Add support for more timeouts to Nexus operations#1276
Add support for more timeouts to Nexus operations#1276Quinn-With-Two-Ns wants to merge 5 commits intotemporalio:mainfrom
Conversation
|
|
0b541a2 to
e1c9abe
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2554cee0e9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| schedule_to_start_timeout: timedelta | None | ||
| start_to_close_timeout: timedelta | None |
There was a problem hiding this comment.
Keep new interceptor timeout fields optional
StartNexusOperationInput is part of the public interceptor API, but these newly added fields are required constructor args, which is a backwards-incompatible break for existing interceptors that instantiate this dataclass (or pass positional args) using the prior signature. After this change, older code will either raise TypeError for missing args or mis-bind positional values, so adding defaults (e.g., None) is needed to preserve compatibility while introducing the new timeouts.
Useful? React with 👍 / 👎.
| nexus_task_executor=concurrent.futures.ThreadPoolExecutor(), | ||
| ): | ||
| await create_nexus_endpoint(task_queue, client) | ||
| try: |
There was a problem hiding this comment.
I prefer pytest.raises, but no big deal.
| @workflow.defn | ||
| class StartToCloseTimeoutTestCallerWorkflow: | ||
| @workflow.init | ||
| def __init__( |
There was a problem hiding this comment.
Any particular reason to create the nexus client as a member? Not that it matters too much in the test, but if we're viewing all code as AI consumed, is this a good pattern to suggest?
There was a problem hiding this comment.
That's actually what all the tests in this file do so i just copied them for consistency.
Add schedule-to-start and start-to-close for Nexus operations
992fdfb to
c76138c
Compare
Add schedule-to-start and start-to-close for Nexus operations
NOTE, before this can be merged the API still needs to be tagged, core changes need to be merged and tests need to be added
Note
Medium Risk
Touches Nexus operation invocation plumbing and protobuf command fields, which can affect runtime scheduling/timeout behavior across workflows. Changes are scoped and covered by new timeout-focused tests.
Overview
Adds support for passing
schedule_to_start_timeoutandstart_to_close_timeoutwhen starting/executing Nexus operations, threading these options from the publicNexusClient.start_operation/execute_operationAPI through worker runtime wiring into theScheduleNexusOperationcommand.Extends error coverage with new tests asserting Nexus operations surface
TimeoutErrorwithTimeoutType.SCHEDULE_TO_STARTandTimeoutType.START_TO_CLOSEwhen these timeouts elapse.Written by Cursor Bugbot for commit c76138c. This will update automatically on new commits. Configure here.