Conversation
…aned jobs reconcile_orphaned_jobs released the dead job's item claim but never touched the item's labels, so an item dispatch had already swapped from ready-for-work to dispatched stayed stuck on dispatched forever after a daemon crash/restart -- invisible to run_discovery_tick, which only ever looks at ready-for-work. Swap the label back (mirroring dispatch_item's own swap in reverse) unless the item was independently completed or cancelled while the job was still marked running. Split reconcile_orphaned_jobs and its tests out of dashboard/server.rs into dashboard/orphan_reconcile.rs to stay under the repo's LOC gate. Agentflare-Agent: claude-code Agentflare-Branch: task/99 Agentflare-Item: 99
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 26 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
Comment |
execute_work's "claim succeeded but no worktree was created" and "failed to chdir into <worktree>" paths were structural git-state failures (e.g. a stale prunable worktree registration, confirmed live for items #465/#466) that retry identically every time, but went through the normal max_retries backoff budget before the terminal- failure recovery hook could swap the item off `dispatched`. Add a `fatal` flag to JobFailure/WorkOutcome that Queue::fail uses to skip straight to terminal `state=failed` regardless of retries remaining, and set it on those two setup-failure branches. Agent-run failures are unaffected and keep the existing retry/cooldown behavior. dispatch_item's ready-for-work/dispatched label-flip timing is untouched. Agentflare-Agent: claude-code Agentflare-Branch: task/467-fail-fast-on-structural-worktree-setup-f Agentflare-Item: 467
1 participant
Working tree is clean with the fix committed.
Summary
Fixed item #99:
reconcile_orphaned_jobs(daemon startup, on a crash/restart) released the dead job'sitem_claimslease but never touched the item's labels. Sincedispatch_itemhad already swappedready-for-work→dispatchedwhen the job was first sent out, andrun_discovery_tickonly ever looks forready-for-workitems, an orphaned item was claim-free but permanently invisible to auto-dispatch — stuck until a human manually relabeled it.Fix (
src/dashboard/orphan_reconcile.rs, new file): addedrestore_ready_for_work, called after each orphaned in-process job's claim is released. It swapsdispatchedback toready-for-work— the reverse ofdispatch_item's own swap — but skips items already in acompleted/cancelledstate group (same exclusionitem::claim's handoff-freeze check uses), so an item a human finished or cancelled out-of-band while its job was still markedrunningdoesn't get silently resurrected onto the discovery queue.I deliberately did not clear the stale
assignee_agent— tracingresolve_agentinsrc/cli/work.rsshowed the codebase already relies on a staleassignee_agentsurviving a normal (non-crash) job failure to route retries back to the same agent; clearing it here would be an inconsistent special case for no real benefit.Added a test,
reconcile_orphaned_jobs_restores_ready_for_work_label, alongside the existing claim-release test, asserting the item ends up withready-for-work(notdispatched) after reconciliation.Moving
reconcile_orphaned_jobs+ the two tests into their own file was necessary to keepdashboard/server.rsunder the repo's 1500-line LOC gate (it was already sitting exactly at the limit before this change). Verified:cargo build, targetedcargo test(dashboard/supervisor modules, 60 tests),cargo clippy,cargo fmt --check, andscripts/loc-gate.shall pass.