fix(fleet): 24 of the 25 "stranded" locations were merged PRs - #40
Merged
Conversation
The guard shipped yesterday reported 25 stranded locations and 26 unpushed
commits, oldest 25 days. `gh pr list --state all` says MERGED for 24 of them.
Every single one.
The mechanism is the fleet's own happy path. An agent branches in a worktree,
pushes, opens a PR, it squash-merges, GitHub deletes the remote branch, and a
later `fetch --prune` drops the tracking ref. What survives is a local branch
whose `branch.<n>.merge` is still configured and no longer resolves.
`rev-parse @{u}` fails on that, so the old code took the same path as a branch
that was never pushed at all and fell through to origin/main — where the
pre-squash commit is unreachable by construction, because main received
different sha carrying the same content. The count could therefore never reach
zero. It was not a stale number; it was a permanent one.
Upstream GONE is the opposite fact from upstream ABSENT: it is proof the branch
DID leave the machine, which is precisely what puts it out of scope for a guard
whose stated job is finding work GitHub cannot see. So read the config with
for-each-ref and check whether the tracking ref resolves, instead of asking one
question that both states answer the same way.
Three tests pin it, including the must-still-fire half — never-pushed work and
work ahead of a live upstream both still count. Reverting the fix turns the
first of them red.
Fleet after: 6 locations, 1 unpushed commit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This was referenced Aug 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
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.
fleet-strandedreported 25 stranded locations, 26 unpushed commits, oldest 25 days. I checked all 24 pruned-branch cases against GitHub:gh pr list --state allreturns MERGED for every one.Mechanism
The fleet's happy path is the bug trigger:
fetch --prunedrops the tracking refbranch.<n>.mergepointing at a ref that no longer resolvesrev-parse @{u}fails on step 4, so the old code took the same branch as never pushed and fell through toorigin/main— where the pre-squash commit is unreachable by construction, since main got a different sha with the same content. The count could never reach zero. Not a stale number, a permanent one.Fix
upstream GONE≠upstream ABSENT. The first is proof the branch did leave the machine, which is exactly what puts it out of scope for a guard whose job is finding work GitHub cannot see. Read the config withfor-each-ref, then check whether the tracking ref resolves.Tests
Three added, including the must-still-fire half:
got 1)24 passed, 0 failed.Result
Same class as the four gates fixed yesterday: judging state that does not belong to the commit being checked.
🤖 Generated with Claude Code