_pick_next_task resumes IN_PROGRESS tasks before scanning for PENDING (closes #999)#1000
Merged
Merged
Conversation
…closes #999) confusio worker stuck looping every 60s on PR #288 with no task progress for ~10 minutes. Trace showed `execute_task` returning 0 every cycle while the active task remained `in_progress`, then the promote gate (added in #989) correctly seeing the in_progress task and refusing to promote past it. Deadlock: worker can neither pick up the in_progress task nor advance to merge. Root cause: `_pick_next_task` filtered tasks to `status == PENDING` only, so any task left in_progress by an iteration that ended abnormally (subprocess crash, fido self-restart, kill) became invisible to the picker. Before #989 this was masked because the promote gate let the in_progress task slip through; #989 closed that hole and exposed the picker's blind spot. Fix: include IN_PROGRESS in the eligible candidates and prioritise it over PENDING — finishing what we already started keeps tasks.json honest before we reach for new work. ASK/DEFER prefixes still suppress IN_PROGRESS (those signals mean a task is awaiting a human, not a signal to resume). Tests: 4 new TestPickNextTask cases covering IN_PROGRESS over PENDING, IN_PROGRESS over CI-PENDING, lone IN_PROGRESS returned, and ASK-prefixed IN_PROGRESS still suppressed. Existing 15 cases still pass.
43cd368 to
831c6eb
Compare
rhencke
approved these changes
Apr 26, 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
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.
Summary
Closes #999 — confusio worker deadlock where an
IN_PROGRESStask was invisible to_pick_next_taskand the #989 promote gate (correctly) refused to promote past it.Diagnosis
Trace from
~/log/fido.log, ~23:44Z–23:55Z (10 min stuck loop on PR #288):execute_taskreturned 0 every cycle because_pick_next_taskfiltered tostatus == PENDINGonly. The active task wasIN_PROGRESS(left there by an earlier iteration that ended without claude running./fido task complete). Combined with #989's promote gate, the worker had no way out.Before #989 this was masked — the promote gate let the in_progress task slip through and the PR got marked ready while work was still in flight (the original #988 symptom). #989 closed that hole; this PR fixes the picker so the cycle completes.
Fix
_pick_next_tasknow treatsIN_PROGRESSas the highest-priority candidate (resume what we already started), then falls back to CI tasks, then list-order PENDING. ASK/DEFER prefixes still suppress IN_PROGRESS — those signals mean a task is waiting for a human, not a signal to resume.Test plan
TestPickNextTaskcases: IN_PROGRESS over PENDING, IN_PROGRESS over CI, lone IN_PROGRESS returned, ASK-prefixed IN_PROGRESS still suppressedTestPickNextTaskcases still pass./fido cigreentask 1/2 — Extend validation scriptsresumes within one worker cycle (≤60s) instead of looping indefinitely🤖 Generated with Claude Code