Repository navigation
Conversation
…tch fails driveFailed called failRun, which ends the run but leaves the task in its current stage. A task still sitting in a claimable stage is claimed again on the next poll, so a worker that fails every attempt produces an unbounded claim/dispatch/fail loop: a new run and a new workspace per tick, and the ticket never moves. Reproduced against nulltickets with a worker whose dispatch always returns 500 and poll_interval_ms 1000: 10 runs in 20 seconds, task still in its initial stage. After the change: one run, task in the configured failure stage. WorkflowDef already carries on_failure.transition_to and defaults it to "failed"; it was never read on this path. Apply it, and fall back to failRun when no transition is configured or the pipeline rejects the trigger, so the run is closed out either way. This does not add backoff or a dead letter. A pipeline that rejects the configured trigger still loops, and that case now logs a warning naming the trigger and the stage. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This was referenced Oct 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
When a tracker dispatch fails and there are no retries left, the task is now moved with the workflow's
on_failure.transition_totrigger before the run is failed. If no trigger is configured, or the pipeline rejects it, the run is failed exactly as before, and the rejected case logs a warning.Why
driveFailedonly callsfailRun. That ends the run but leaves the task in its current stage, which is still claimable. On the next poll the same task is claimed again, so a worker that fails every attempt produces an unbounded claim → dispatch → fail loop: a new run and a new workspace per tick, and the ticket never moves.WorkflowDef.on_failure.transition_toalready exists and defaults to"failed", but nothing read it on this path.Validation
zig buildis clean.zig build test: 355/355 pass.bash tests/test_e2e.sh: 57/57 pass.main) using a pipelinetodo → failed(triggerfailed), adispatchworkflow, a webhook worker that always returns 500, andpoll_interval_ms: 1000. Results after 20 s:todo;failed.Not in scope
There's no backoff and no dead-letter. A pipeline whose definition rejects the configured failure trigger still loops as it does today, but now logs
failure transition '<trigger>' rejected for task <id>; task stays in stage <stage>, so the misconfiguration is visible.🤖 Generated with Claude Code