Repository navigation
BREAKING CHANGE: track nextTaskId to prevent timeout race with long-running task scheduling duplicate repeat tasks, remove retryOnTimeoutCount - #11
Conversation
…unning task scheduling duplicate repeat tasks, remove retryOnTimeoutCount
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![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: 3c98fd214d
ℹ️ 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".
| const claimedTask = await Task.findOneAndUpdate( | ||
| { _id: task._id, nextTaskId: null }, | ||
| { $set: { nextTaskId } }, | ||
| { returnDocument: 'before' } |
There was a problem hiding this comment.
If timeout expiry successfully sets nextTaskId but the subsequent Task.create() fails, the parent permanently points to a nonexistent successor. When the still-running handler later finishes, its scheduling attempt fails this claim check and silently returns, stopping the repeating task chain. Before this change, that handler completion could retry creating the successor. Make successor creation recoverable, for example by allowing subsequent callers to idempotently create the already-claimed successor.
Useful? React with 👍 / 👎.
No description provided.