What happened?
Town ef9a9aca-760b-49fe-88c1-ad18eccfc060, rig razoredge (2f79fdd2-8874-4181-a34e-8fd001053010).
Recurring patrol/control-server bug. Since ~06:24 UTC the patrol loop has been creating gt:triage batch beads ("Triage batch: N request(s)") that immediately fail at dispatch_attempts=0 — they are never dispatched to a polecat. ~100 such failed beads accumulated; the loop regenerates a new failed triage bead roughly every 90 seconds. This generates continuous escalations to the mayor (e.g. medium escalation c4e10378, and a prior high-severity doom-loop escalation 140ef682 which a triage-request already resolved to ESCALATE_TO_MAYOR).
Observed/verified facts:
- Every failed gt:triage bead has dispatch_attempts=0 and last_dispatch_attempt_at=null.
- The triage dispatch "Situations to Assess" prompt is empty / claims N requests but provides no beads or situations.
- GET /triage endpoints reportedly return HTTP 500 (per the prior escalation's resolution notes).
- All agents are healthy/idle; git connectivity is fine.
- This is NOT a stuck agent or a real pending triage request.
Likely cause: phantom triage_request count on the control server + failing /triage endpoints + dispatch never firing. Needs operator investigation of the control server / patrol scheduler.
Additional secondary finding (separate but blocks cleanup): the gt_bead_delete tool rejects ANY array input with "404 Bead not found" even though the schema documents array support for bulk-delete up to 5000. Single-string bead_id deletes succeed. This prevented me from purging the 100-bead backlog (single-deleting is impractical against a 90s regen cycle).
Impact: constant noise + escalations; no productive work is blocked (agents idle), but the bead board is flooded and mayor attention is repeatedly consumed.
Area
Agent Dispatch / Scheduling
Context
- Town ID: ef9a9aca-760b-49fe-88c1-ad18eccfc060
- Agent: Mayor (cbf9c6c1-ef23-406c-b420-ab4a0b0da96c)
- Rig ID: 2f79fdd2-8874-4181-a34e-8fd001053010
Recent Errors
Gastown API error (404): Bead not found (returned for every gt_bead_delete call passing an array, including a 2-item array of confirmed-valid IDs; single-string deletes succeed).
Filed automatically by the Mayor via gt_report_bug.
What happened?
Town ef9a9aca-760b-49fe-88c1-ad18eccfc060, rig razoredge (2f79fdd2-8874-4181-a34e-8fd001053010).
Recurring patrol/control-server bug. Since ~06:24 UTC the patrol loop has been creating gt:triage batch beads ("Triage batch: N request(s)") that immediately fail at dispatch_attempts=0 — they are never dispatched to a polecat. ~100 such failed beads accumulated; the loop regenerates a new failed triage bead roughly every 90 seconds. This generates continuous escalations to the mayor (e.g. medium escalation c4e10378, and a prior high-severity doom-loop escalation 140ef682 which a triage-request already resolved to ESCALATE_TO_MAYOR).
Observed/verified facts:
Likely cause: phantom triage_request count on the control server + failing /triage endpoints + dispatch never firing. Needs operator investigation of the control server / patrol scheduler.
Additional secondary finding (separate but blocks cleanup): the gt_bead_delete tool rejects ANY array input with "404 Bead not found" even though the schema documents array support for bulk-delete up to 5000. Single-string bead_id deletes succeed. This prevented me from purging the 100-bead backlog (single-deleting is impractical against a 90s regen cycle).
Impact: constant noise + escalations; no productive work is blocked (agents idle), but the bead board is flooded and mayor attention is repeatedly consumed.
Area
Agent Dispatch / Scheduling
Context
Recent Errors
Filed automatically by the Mayor via
gt_report_bug.