Document new Nexus Operation timeouts#4242
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📖 Docs PR preview links
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ebd51b89d5
ℹ️ 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".
|
|
||
| Once the caller Workflow schedules an Operation with the caller's Temporal Service, the caller's Nexus Machinery keeps trying to start the Operation. | ||
| If a [retryable Nexus error](/references/failures#nexus-errors) is returned the Nexus Machinery will retry until the Nexus Operation's Start-to-Close-Timeout is exceeded. | ||
| If a [retryable Nexus error](/references/failures#nexus-errors) is returned the Nexus Machinery will retry until the Nexus Operation's [Schedule-to-Close timeout](#schedule-to-close-timeout) is exceeded. |
There was a problem hiding this comment.
This sentence says Nexus start retries continue until Schedule-to-Close, but the same page now documents Schedule-to-Start as the timeout for how long an operation may wait to be started (docs/encyclopedia/nexus-operations.mdx, line 218). In configurations where Schedule-to-Start is set lower than Schedule-to-Close (for example, no handler workers available), retries stop at Schedule-to-Start, so this wording gives readers the wrong timeout boundary for failure analysis and tuning.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
It would retry until the minimum of schedule to close and schedule to start.
prasek
left a comment
prasek
left a comment
There was a problem hiding this comment.
lgtm, dropped a few suggestions
| For asynchronous Operations, this timeout covers the full lifecycle: scheduling, starting, and completing. | ||
| For synchronous Operations, this timeout covers the time from scheduling to receiving the result. | ||
|
|
||
| In Temporal Cloud, the maximum Schedule-to-Close timeout is 60 days. |
There was a problem hiding this comment.
| In Temporal Cloud, the maximum Schedule-to-Close timeout is 60 days. | |
| In Temporal Cloud, the [maximum Schedule-to-Close timeout is 60 days](https://docs.temporal.io/cloud/limits#nexus-operation-duration-limits). |
| This is the overall timeout for the entire Operation. | ||
| The Nexus Machinery [automatically retries](#automatic-retries) failed requests internally until this timeout is exceeded, at which point the Operation fails with a [NexusOperationTimedOut](/references/events#nexusoperationtimedout) event. | ||
|
|
||
| For asynchronous Operations, this timeout covers the full lifecycle: scheduling, starting, and completing. |
There was a problem hiding this comment.
| For asynchronous Operations, this timeout covers the full lifecycle: scheduling, starting, and completing. | |
| This timeout covers the full [Nexus Operation lifecycle](https://docs.temporal.io/nexus/operations#operation-lifecycle). Asynchronous Operations are scheduled, started, and completed. Synchronous Operations don't have an intermediate started state because they complete as part of the start request. |
4 participants
What does this PR do?
Document new Nexus Operation timeouts
schedule-to-startandstart-to-close. We also didn't have any docs I could find forschedule-to-closeso I added that. I think it would be good to show how to set these on a PR SDK basis as well, I was planning to put that in another PR.Notes to reviewers
┆Attachments: EDU-5951 Document new Nexus Operation timeouts