fix(bridge,work): surface why a claimed item never gets worked - #423
Merged
Conversation
Two diagnosability gaps found while chasing why a bridge-claimed
issue sat untouched for 40+ minutes:
- record_claim only decides ready-for-work labeling once, at first
claim, and stays silent when no work_agent is configured -- an
issue claimed before AGENTFLARE_BRIDGE_WORK_AGENT is set (or
claimed on a workstation that never sets it) looks identical to
one actively being worked, with nothing pointing at the real
cause. Log it.
- `agentflare work`'s claim-status handling formatted every non-
acquired claim as "held by {owner} ({age}s)", but
ClaimOutcome::BlockedByAssignee (an unaccepted handoff) has no
owner/age_secs fields at all -- producing the meaningless "held
by ? (0s)" instead of the actionable reason already carried in
the response.
Agentflare-Agent: claude-code
Agentflare-Branch: bridge-claim-diagnostics
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe CLI now distinguishes blocked handoffs from held claims. The GitHub bridge warns when new claims lack a configured ChangesClaim reporting and dispatch
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
This was referenced Aug 10, 2026
getappz
added a commit
that referenced
this pull request
Aug 11, 2026
…ge collisions (#456) * git-shim/worktree residual polish: teardown messaging, branch-create accuracy, stranded-checkout recovery - worktree deny message now distinguishes provisioning (claim) from teardown (check_merge/release/audit --prune) so an agent denied mid-teardown gets the exact cleanup action (vent #350) - is_branch_create() classifies checkout -b/-B and switch -c/-C; canonical-checkout deny says 'create a new branch' instead of the misleading 'would detach HEAD' (vent #395) - audit_orphans flags worktrees stranded on the default branch (intact gitdir) so worktree audit --prune clears the gh pr merge --delete- branch / post-merge-sync collision root cause (vents #351/#394/#423) - AGENTFLARE_GIT_ALLOW_CANONICAL_MUTATE now also lifts the default-branch checkout/switch deny in the canonical checkout, giving stranded checkouts a sanctioned way back (vent #386 residual) - allowlist classify.rs (already 1604L on master) in the LOC gate Agentflare-Agent: 1 Agentflare-Branch: task/441 Agentflare-Item: 441 * fix(git-shim): close branch-create detection gaps, protect dirty stranded worktrees CodeRabbit review on PR #456: - is_branch_create only matched exact -b/-B/-c/-C, missing --orphan (checkout+switch), switch's --create/--force-create long forms, and attached short-option spellings (-bname). Those forms slipped past both would_detach_head and deny_canonical_detach_reason undetected, letting an agent create a branch in the canonical checkout via e.g. 'git switch --orphan x' or 'git checkout -bx' with no deny at all. - audit_orphans' new on-default-branch detection could hand a dirty, uncommitted stranded worktree to gc_orphans for deletion; the only other gc_orphans caller (cleanup_item_worktree) already refuses on a dirty status check first. Apply the same guard here. Agentflare-Agent: claude-code_2-1-227_agent Agentflare-Branch: task/441 Agentflare-Item: 441
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.
Summary
Two diagnosability gaps found while chasing why a GitHub-bridge-claimed issue (#421) sat untouched for 40+ minutes, looking indistinguishable from "actively being worked":
record_claim(github/bridge/tick.rs) decidesready-for-worklabeling once, at first claim, and stays silent when nowork_agentis configured. An issue claimed beforeAGENTFLARE_BRIDGE_WORK_AGENTis set — or on a workstation that never sets it — now logs that it will not be auto-dispatched, instead of silently sitting there.agentflare work's claim-status handling (cli/work.rs) formatted every non-acquiredclaim as"held by {owner} ({age}s)", butClaimOutcome::BlockedByAssignee(an unaccepted handoff) has noowner/age_secsfields — producing the meaningless"held by ? (0s)"instead of the actionablereasonthe claim response already carries.Neither is a behavior change to the claim/dispatch logic itself — both are purely making an existing silent/confusing state observable.
Test plan
cargo test --bin agentflare cli::work::— 26 passedcargo test --bin agentflare github::bridge::tick— 27 passedcargo clippy/cargo fmt --checkclean on both touched filesreasoninsteadSummary by CodeRabbit
Bug Fixes
Improvements