Repository navigation
fix: PR gets two different beacon:flared:<machine> labels from two workstations working the same item - #694
Merged
getappz merged 4 commits intoSep 16, 2026
Conversation
added 3 commits
September 16, 2026 15:18
Agentflare-Branch: task/261-bug-pr-gets-two-different-beacon-flared Agentflare-Item: 261
…PR claim marker Item #261's beacon-duplication bug traced to self_repair_or_gate having zero cross-machine coordination: each workstation's local item db is unsynced, so claim_still_live only ever sees claims recorded by its own process, and any workstation's run_review_sweep tick can independently dispatch self-repair for the same failing PR. Two machines each believing they were first then independently succeed at push_and_open_pr's create+label branch. Adds claim_self_repair, reusing github::bridge::claim's TTL+heartbeat marker resolution (the same optimistic two-step try_claim already uses for issue claiming) against a comment on the PR itself -- a PR is also an issue on GitHub's comments endpoint. Only backs off when another workstation DEFINITELY holds a live claim; any GitHub error along the way fails open toward proceeding, matching find_existing's existing soft-fail philosophy, so a rare missed race is preferred over self-repair silently never running. Agentflare-Agent: claude-code Agentflare-Branch: task/261-bug-pr-gets-two-different-beacon-flared Agentflare-Item: 261 Agentflare-Session: a77e4506-c0ee-48ac-971f-a9c2f413e8dd
Closes the gap in finding 3 of item #261: two workstations independently dispatched to the same item can both pass the pre-create find_existing check (neither sees a PR yet), both call create, and GitHub accepts only one. The loser used to just log create's duplicate-branch error and give up, leaving the item without a linked PR. Now it rechecks find_existing once and links up with the winner's PR instead, using the same is_own_pr trust rule as the pre-create check so it never trusts a stale, unrelated PR that happens to share the branch name. Extracted is_own_pr and recover_pr_after_failed_create so the retry logic is testable against a mock GitHub server, since push_and_open_pr itself needs a real git remote and live credentials. Agentflare-Agent: claude-code Agentflare-Branch: task/261-bug-pr-gets-two-different-beacon-flared Agentflare-Item: 261 Agentflare-Session: 6bc3d75d-5644-42fa-9c13-a11e8c9f472b
Owner
Author
|
Tracking this PR for automated review ( |
|
Warning Review limit reachedNext included review available in 9 minutes. View limit detailsLimit details: You’ve used all 3 included reviews currently available. Your 41 included PR review attempts over the past 7 days set your current allowance at 3 reviews per hour. Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Essentials Run ID: 📒 Files selected for processing (5)
Comment |
getappz
deleted the
task/261-bug-pr-gets-two-different-beacon-flared
branch
September 16, 2026 10:20
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.
Status
Investigated and verified — no further code changes were needed; this branch (3 commits ahead of
origin/master, working tree clean) already carries a complete, tested fix from a prior round of this same task:Root cause (confirmed via code-level tracing, documented in item #261's comment thread):
self_repair_or_gatehas zero cross-machine coordination — each workstation keeps its own unsynced local item DB, so any workstation'srun_review_sweeptick can independently dispatch self-repair for the same in-review PR after a CI failure. Two machines each believed they were first, both reachedpush_and_open_pr's success/label branch, and PR #688 ended up with bothbeacon:labels.Fix (3 defense-in-depth layers, all in already-committed history):
supervisor.rs:claim_self_repair— a GitHub-comment TTL+heartbeat claim marker on the PR (reusinggithub::bridge::claim's existing issue-claim logic) gates self-repair dispatch, so only one workstation proceeds unless the other's claim is stale.worktree/discovery.rs+github/pulls.rs:opened_by_agentflare— skips adopting a PR into a duplicate local item when its body already carries agentflare's own "for item #N via agentflare" stamp, closing the discovery-sweep race window.worktree/mod.rs:recover_pr_after_failed_create— ifpulls::createfails (duplicate-branch error from a true concurrent-create race), rechecksfind_existingonce and links to the winner's PR instead of erroring out or silently duplicating.Verification run this session:
cargo build --workspace --all-targets— cleancargo fmt --check— cleancargo clippy --locked --workspace --all-targets --all-features -- -D warnings -A unsafe_code -A clippy::pedantic(CI's exact flags) — clean, zero warningscargo test --workspace— 1818 passed, 1 unrelated failure, 9 ignoredConcern (not blocking, not in scope):
mcp_prompts::tests::optimize_review_returns_full_skill_bodyfails in this sandbox only —flare_code::state::set_activewrites to~/.local/state/agentflare/..., and this sandbox's writable-home-dirs allowlist (crates/agentflare-jobs/src/sandbox.rs:158) doesn't include.local/state, so the write hitsEROFS. Confirmed by directly touching that path (read-only filesystem) and by the file's own doc comment referencing the same class of prior sandbox issues (#127, #106, #130, #120, #236). Untouched by this diff, unrelated to the beacon-label bug, and wouldn't fail in real CI where that path is writable. This is likely why prior rounds hitMAX_FIX_ROUNDSwithout converging — worth flagging separately, but out of scope to fix here.Item #261's acceptance criteria (confirmed mechanism, fixed, regression tests) are all satisfied by the existing commits; nothing further to change.
Opened by
claude-codeon flared:51bb8de6c33b for item #261 via agentflare.