gc bd assign fails for every rig-store bead, so nothing can be dispatched to a named session #15

New issue

Open

opened 2026-09-06 04:09:07 +00:00 by forgejo-admin · 0 comments

forgejo-admin commented

2026-09-06 04:09:07 +00:00

Owner

gc bd assign and gc bd update --assignee fail for EVERY rig-store bead with
"no issue found matching ", while other writes to the same id succeed.

$ gc bd assign ce-ashq crew-e2e
Error: resolving ce-ashq: no issue found matching "ce-ashq"
$ gc bd assign ce-23gb crew-e2e
Error: resolving ce-23gb: no issue found matching "ce-23gb"
$ gc bd update ce-ashq --assignee gs-wisp-dydpn
Error: 1 of 1 issues failed to update
  ce-ashq: resolving issue: no issue found matching "ce-ashq"

The same id resolves fine for every other write:

$ gc bd update ce-ashq --status in_progress      -> OK
$ gc bd update ce-ashq --description "$(...)"    -> OK
$ gc bd update ce-ashq --add-label hold:mayor    -> OK
$ gc bd show ce-ashq                             -> OK

So the assignee write path resolves the issue through a different route than the
other field writes, and that route does not reach the rig store.

WORKAROUND, and it is proven: run bd directly from inside the rig repo.

$ cd /Users/pbanka/hobby/celilo && bd assign ce-ashq crew-e2e
✓ Assigned ce-ashq — Census: run every e2e suite ... to crew-e2e

WHY THIS IS P1. Assignment is the ONLY way a bead reaches a NAMED session. A
pool reads gc.routed_to; a named session's hook matches the assignee and
nothing else (STANDING-DECISIONS, "Creating the bead is HALF"). Named sessions
here are crew, crew-e2e, the refineries, the mayor, boot and the five witnesses.
While this is broken, nobody can dispatch to any of them through gc, and the
mayor's whole dispatch half is down.

THE SECOND HARM IS THE MESSAGE. "no issue found matching" sends you to look for
a routing or a store problem, which is the wrong place, and BD_DEBUG_ROUTING=1
prints nothing on this path. It cost this session about fifteen minutes of
looking at routes.jsonl and prefix tables before the direct-bd test isolated it.
Whatever the real refusal is, say that instead.

MEASURED 2026-09-06 by gastown.mayor, starting wave 0 of e2e-suite-recovery.
ce-ashq (the full census, holds the e2e lock) sat unassignable because of it.

Bead: gs-7p9q30 (city store).

`gc bd assign` and `gc bd update --assignee` fail for EVERY rig-store bead with "no issue found matching <id>", while other writes to the same id succeed. ``` $ gc bd assign ce-ashq crew-e2e Error: resolving ce-ashq: no issue found matching "ce-ashq" $ gc bd assign ce-23gb crew-e2e Error: resolving ce-23gb: no issue found matching "ce-23gb" $ gc bd update ce-ashq --assignee gs-wisp-dydpn Error: 1 of 1 issues failed to update ce-ashq: resolving issue: no issue found matching "ce-ashq" ``` The same id resolves fine for every other write: ``` $ gc bd update ce-ashq --status in_progress -> OK $ gc bd update ce-ashq --description "$(...)" -> OK $ gc bd update ce-ashq --add-label hold:mayor -> OK $ gc bd show ce-ashq -> OK ``` So the assignee write path resolves the issue through a different route than the other field writes, and that route does not reach the rig store. WORKAROUND, and it is proven: run `bd` directly from inside the rig repo. ``` $ cd /Users/pbanka/hobby/celilo && bd assign ce-ashq crew-e2e ✓ Assigned ce-ashq — Census: run every e2e suite ... to crew-e2e ``` WHY THIS IS P1. Assignment is the ONLY way a bead reaches a NAMED session. A pool reads `gc.routed_to`; a named session's hook matches the assignee and nothing else (STANDING-DECISIONS, "Creating the bead is HALF"). Named sessions here are crew, crew-e2e, the refineries, the mayor, boot and the five witnesses. While this is broken, nobody can dispatch to any of them through `gc`, and the mayor's whole dispatch half is down. THE SECOND HARM IS THE MESSAGE. "no issue found matching" sends you to look for a routing or a store problem, which is the wrong place, and `BD_DEBUG_ROUTING=1` prints nothing on this path. It cost this session about fifteen minutes of looking at routes.jsonl and prefix tables before the direct-bd test isolated it. Whatever the real refusal is, say that instead. MEASURED 2026-09-06 by gastown.mayor, starting wave 0 of e2e-suite-recovery. ce-ashq (the full census, holds the e2e lock) sat unassignable because of it. Bead: `gs-7p9q30` (city store).

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#15

No description provided.

Rows
Columns