The refinery's find-work query filters --status=open, so a bead stuck in_progress on its own hook is invisible to it and it reports idle while holding it #7

New issue

Open

opened 2026-09-03 06:25:34 +00:00 by forgejo-admin · 0 comments

forgejo-admin commented

2026-09-03 06:25:34 +00:00

Owner

What happens

mol-refinery-patrol's find-work step queries:

gc bd list --rig=$GC_RIG --assignee=$GC_AGENT --status=open \
  --exclude-type=epic --has-metadata-key=branch --limit=1

--status=open means a bead that is in_progress and assigned to the refinery is invisible to the refinery. Nothing else scans for it either: the formula's orphan-merge fallback filters --status=open too.

So a bead that reaches in_progress on the refinery's hook and then stops being worked is stranded permanently. The refinery reports "IDLE: no work, exiting turn" while holding it, and the queue reads empty when it is not.

Measured, 2026-09-02

ce-eltf sat in_progress assigned to celilo/gastown.refinery from 13:18Z. The refinery ran its find-work query at least six times across the afternoon and reported IDLE every time. The mayor found it by scanning independently and mailed evidence at 21:21Z, eight hours later. It took a human-directed agent noticing, which is exactly the channel that does not scale.

That bead was in fact already landed, its work having reached main through a stacked branch, so nothing was lost. That is luck, not the mechanism working. Had it been unlanded work it would have sat just as invisibly.

Why it is hard to see

The refinery is not wrong about anything it can observe. Its query is well-formed, returns cleanly, and returns nothing. "No rows" and "no work" are the same answer, and only the second one is true.

gc bd list --status in_progress from outside shows the bead immediately. The information exists; the agent holding the bead is the one party that cannot see it.

Suggested fix

Widen the find-work query to include in_progress beads assigned to this agent, and handle them first — a bead already in_progress on your own hook is by definition the thing you were doing.

If that risks double-claiming, the narrower version is a second query run only when the first returns empty: before concluding IDLE, ask whether anything is in_progress under this assignee, and escalate rather than exit if so. Reporting idle while holding work should be impossible, not merely unlikely.

The orphan-merge fallback needs the same widening for the same reason.

Workaround now in place

This city cannot re-pin the pack, so the workaround is written into REFINERY.md at the city root, which the refineries read: on wake, before concluding idle, run

gc bd list --rig <rig> --status in_progress --json | jq '.[] | select(.assignee|test("refinery"))'

That is a rule an agent has to remember, which is strictly worse than a query that cannot lie. Recorded here so the real fix is not forgotten because the symptom stopped.

Environment

Pack pinned at sha:3b3b89f2011e06d84459aa7bea1552382f13930a. gc 88f3894ad-dirty. City /Users/pbanka/gc-scratch. Originally filed as bead ce-uh79 in the celilo store, which was the wrong home: the fix lands in the pack, so no celilo polecat could ever action it.

## What happens `mol-refinery-patrol`'s find-work step queries: ``` gc bd list --rig=$GC_RIG --assignee=$GC_AGENT --status=open \ --exclude-type=epic --has-metadata-key=branch --limit=1 ``` `--status=open` means a bead that is **in_progress and assigned to the refinery** is invisible to the refinery. Nothing else scans for it either: the formula's orphan-merge fallback filters `--status=open` too. So a bead that reaches `in_progress` on the refinery's hook and then stops being worked is stranded permanently. The refinery reports "IDLE: no work, exiting turn" while holding it, and the queue reads empty when it is not. ## Measured, 2026-09-02 `ce-eltf` sat `in_progress` assigned to `celilo/gastown.refinery` from 13:18Z. The refinery ran its find-work query at least six times across the afternoon and reported IDLE every time. The mayor found it by scanning independently and mailed evidence at 21:21Z, **eight hours later**. It took a human-directed agent noticing, which is exactly the channel that does not scale. That bead was in fact already landed, its work having reached main through a stacked branch, so nothing was lost. That is luck, not the mechanism working. Had it been unlanded work it would have sat just as invisibly. ## Why it is hard to see The refinery is not wrong about anything it can observe. Its query is well-formed, returns cleanly, and returns nothing. "No rows" and "no work" are the same answer, and only the second one is true. `gc bd list --status in_progress` from outside shows the bead immediately. The information exists; the agent holding the bead is the one party that cannot see it. ## Suggested fix Widen the find-work query to include `in_progress` beads assigned to this agent, and handle them first — a bead already in_progress on your own hook is by definition the thing you were doing. If that risks double-claiming, the narrower version is a second query run only when the first returns empty: before concluding IDLE, ask whether anything is `in_progress` under this assignee, and escalate rather than exit if so. Reporting idle while holding work should be impossible, not merely unlikely. The orphan-merge fallback needs the same widening for the same reason. ## Workaround now in place This city cannot re-pin the pack, so the workaround is written into `REFINERY.md` at the city root, which the refineries read: on wake, before concluding idle, run ``` gc bd list --rig <rig> --status in_progress --json | jq '.[] | select(.assignee|test("refinery"))' ``` That is a rule an agent has to remember, which is strictly worse than a query that cannot lie. Recorded here so the real fix is not forgotten because the symptom stopped. ## Environment Pack pinned at `sha:3b3b89f2011e06d84459aa7bea1552382f13930a`. gc `88f3894ad-dirty`. City `/Users/pbanka/gc-scratch`. Originally filed as bead `ce-uh79` in the celilo store, which was the wrong home: the fix lands in the pack, so no celilo polecat could ever action it.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

celilo/gascity-packs#7

No description provided.

Rows
Columns