mol-dog-stale-db's final bd close never succeeds from a pool session: claim identity (session id) vs actor (pool name) mismatch, every run exits 1 #9
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?
The mol-dog-stale-db formula's single step ends with
bd close "$WORK_BEAD" --reason "...". From a pool session (bd.dog) this close ALWAYS fails, so every run exits 1 and the wisp stays in_progress until someone closes it by hand.Measured 2026-09-11 on two consecutive order runs (wisps gs-ql0itd and gs-1ognoz). Both times the step completed all its work, attached the scan report, and then:
Cause:
gc hook --claimrecords the claim under the session identity (gs-vuaano), but when the formula step later runsbd close, bd resolves the acting identity to the pool name (bd__dog-1-pool). The identities never match, so a plain close can never succeed from this pool. The error's own remedy, --force, works, and the operator workaround both times wasbd close <id> --force.Workaround used (recorded per the standing rule): manual
bd close <bead> --force --reason "Stale DB scan complete (...)"after each run. Drain-ack still succeeds, so the controller is not blocked, but every wisp from this formula is left open by the formula itself.Fix direction, for the pack author to choose: either close with
--forcein the formula (it is the same agent that claimed the work one interaction earlier), or have the hook/claim path export an identity bd accepts for the close.Related but distinct: gascity-packs#8 covers literal {{var}} placeholders in the same formula.