Conversation
… on any item with an abandoned claim The item_id branch's "safe to relabel" check used claim::current_owner, which deliberately includes stale-but-undone claims (its own doc comment: "so stale locks can be cleaned up"). A claim row only ever leaves status='claimed' via claim::done, which only runs on the normal in_review -> completed promotion. Any item whose work was interrupted or manually rescued outside that flow (crash, human takeover) kept a permanently "claimed" row, so current_owner never went None again -- silently vetoing ready-for-work re-labeling on every future handoff to that item, with no error surfaced anywhere. Swapped in a TTL-aware liveness check (the same primitive quota::decide's tier 4 and the GitHub bridge's own claim-liveness check already use), so an expired claim is correctly treated as no claim -- matching what "safe to re-queue" actually means. Also thread Decision::reason through EffectiveAction::Wait and log each waiting/cooling-down ready-for-work item per tick, plus a `waiting` count in the daemon's summary line, so a labeled item sitting idle for many ticks is visible in the log instead of looking identical to "no eligible items exist" -- exactly what made this bug take an hour of manual item-diffing to notice. A related stale-completed_at issue (item::update_state's "started" branch never clearing a prior completed_at) was root-caused too but is not included here: crates/agentflare-backend/src/item.rs is already past the repo's 2000-line frozen-file LOC gate on master (pre-existing, unrelated to this change), so any edit to it is currently unlandable without first splitting the file. Confirmed that fix is not required to unblock item #66 -- its sole blocker was a missing ready-for-work label, fixed as a data-only change (no code path reads completed_at for dispatch eligibility at all). Agentflare-Agent: claude-code Agentflare-Branch: task/82 Agentflare-Item: 82
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 40 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 |
getappz
changed the title
Agentflare-Agent: claude-code Agentflare-Branch: task/82 Agentflare-Item: 82
Reconciles per-project folder_path dispatch (item #63) with item #82's waiting/Wait(reason) tracking and cooling-down/wait logging, which landed to master independently (#446) while this branch was open. Both behaviors kept: dispatch_item still threads folder_path, and both the cooldown and Wait branches now log + increment waiting. All 19 supervisor:: tests pass, fmt clean, clippy clean (CI flags). Agentflare-Agent: claude-code Agentflare-Branch: task/63 Agentflare-Item: 63
1 participant
Summary
Root causes confirmed (via code reading + live DB inspection, not guessing):
Case 1 (real bug, fixed) —
handoff(item_id=X)'s "safe to re-label" check insrc/mcp_server/handoff.rsusedclaim::current_owner, which deliberately includes stale-but-undone claims (its own doc comment says so — it exists for lock-cleanup tooling). A claim row only ever leavesstatus='claimed'viaclaim::done, which only fires on the normal in_review→completed promotion. Any item whose work was interrupted or manually rescued outside that flow kept a permanentlyclaimedrow, socurrent_ownernever returnedNoneagain — silently vetoingready-for-workre-labeling on every future handoff to that item, forever, with zero error. Fixed by swapping in a TTL-aware liveness check (has_active_claim_by_other), the same primitivequota::decidetier 4 and the GitHub bridge already use elsewhere.Case 2 hypothesis — refuted. Read
list_by_label,run_discovery_tick, andquota::decide::decideend to end: nothing anywhere gates oncompleted_at. Direct DB inspection showed item [ponytail#532] Persona wording: lazy = less work for same result #66's actual blocker was that it simply had noready-for-worklabel (only a leftoverdispatchedlabel) — its claim was already correctly markeddone. Confirmed by re-adding the label: the (unmodified, already-running) daemon picked it up and enqueued a job within one tick.Real but separate bug found:
item::update_state's"started"branch never clears a stalecompleted_at, so a reopened item can showcompleted_at < started_atforever — this is what produced [ponytail#532] Persona wording: lazy = less work for same result #66's specific stale timestamp, and corrupts standup/health velocity bucketing (which keys offcompleted_at). I wrote and tested the fix, but could not commit it:crates/agentflare-backend/src/item.rsis already at 2139 lines against the repo's 2000-line frozen-file LOC gate onmaster— pre-existing debt unrelated to this task. Landing it would require first splitting the file, which is out of scope here. Confirmed this fix isn't needed to unblock [ponytail#532] Persona wording: lazy = less work for same result #66.Visibility: threaded
Decision::reasonthroughEffectiveAction::Waitand added per-item logging plus awaitingcount in the daemon summary line, so a labeled item stuck for many ticks is now visible in the log instead of indistinguishable from "no eligible items."Committed (
cc8e3ad): the handoff fix, the visibility improvement, and regression tests (an_explicit_item_id_handoff_labels_an_item_with_only_a_stale_claim, plus an assertion on the cooldown test). All 40+44 relevant tests pass.Item #66: manually re-labeled
ready-for-work(data-only fix) and confirmed dispatched — jobCeUJQf7EUe4eTCXQFqsffis queued, waiting on a freework_max_concurrencyslot (ironically, the very thing item #66 itself is about).Left for a human: the
update_statecompleted_at fix is written and tested but not committed, blocked by the pre-existing LOC gate onitem.rs— worth a follow-up decision (split the file vs. adjust the gate) before it can land.