gc bd close refuses a pool session's own claimed bead: claim assigns by session id, close resolves actor by session name #20
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What happened
The
mol-dog-stale-dbformula ends with a plainbd close "$WORK_BEAD". That close fails every time for a pool-claimed bead, because the claim and the close resolve the actor differently.gc hook --claimsets the bead's assignee to the session id (gs-yq41kt).gc bd closeresolves the acting identity as the session name (bd__dog-1-pool).So the close refuses:
Reclaiming does not help: the bead is already assigned to this session's own id, and
gc hook current --id-onlyreturns that same id, so the two identities never line up from inside the session.Impact
Every routine maintenance run through this pool hits it. The scan completes, the report note lands, and then the last formula step fails, so either the bead sits open (which is what the formula is designed to prevent) or the agent escalates to
--forceto close its own assigned work (what actually happened, on beadgs-v7kl14on 2026-09-07).--forcedefeats the assignee guard precisely because the guard's identity comparison is wrong for pool sessions, not because anything suspicious is happening.Expected
A session that holds a claim should be able to close the bead it claimed without
--force. The claim identity and the close actor should resolve to the same thing (either both session id or both session name, consistently).Environment
gs-v7kl14(wisp, pool routebd.dog), assigneegs-yq41kt, session namebd__dog-1-poolgc bd close gs-v7kl14 --reason "..."→ refuses;--force→ closesgc hook --claim --drain-ack --json→ actionwork, assigneegs-yq41ktWorkaround used
gc bd close <id> --forceafter confirming the bead is this session's own claim. Filed per the city convention for gc defects (issue, no bead).Another occurrence, 2026-09-09, on the mol-dog-stale-db formula run by pool session bd__dog-2-pool (bead gs-opxv21). The env names the mechanism exactly. The gc hook exports GC_SESSION_ID=gs-q1eodp and records the claim assignee as that id. Plain bd resolves its actor from BEADS_ACTOR=bd__dog-2-pool, which gc sets to the session name. The formula's bd close compares the id against the name and refuses: cannot close gs-opxv21: assignee is "gs-q1eodp", actor is "bd__dog-2-pool". So every formula that claims through gc hook and closes through plain bd close fails its own final step and needs --force. Workaround used: bd close --force, as the refusal message suggests. The scan itself was clean (0 orphans, 0 procs, 0 bytes) and the report was appended to the bead, so only the close was affected.