What happened?
In town 6b110d52-9a70-4742-91d8-fab68a2bec3c (rig nx.ts, id 905bf756-546a-484c-9b4e-1a0b6b903457), the patrol service has been generating a new issue bead every ~60 seconds with title Triage batch: N request(s) and body Process all pending triage request beads and resolve each one.
Each one is dispatched to a polecat (Toast, agent id 05563fc2-0404-4219-8e34-e2e88d657355), fails with dispatch_attempts hitting 5 within ~1 minute, and a new identical bead is created immediately by patrol.
In a 41-minute window (11:31–12:12 UTC today, 2026-06-23), 23 such beads accumulated as status=failed. After bulk-deleting them, more appeared within minutes.
Root cause is likely: (a) patrol itself is healthy but every dispatch fails because the underlying triage identity has a 403 mismatch (separate escalation already filed), and (b) patrol has no back-off or dedup on failed-dispatch. So it spins forever.
Impact: dashboard is unreadable, mayor has to bulk-delete failed triage beads repeatedly, polecat compute is wasted.
Expected: patrol should stop creating new triage-batch beads if the previous N (e.g. 3) failed within a short window, or until the triage identity is repaired. Alternatively, patrol should back off exponentially.
Reproduction: log into town 6b110d52 dashboard, watch the failed filter over 5 minutes — at least 5 new Triage batch: N request(s) beads appear.
Related: triage identity mismatch (403) escalation, separately reported.
Severity: medium. Not blocking work, but unusable dashboard.
Area
Agent Dispatch / Scheduling
Context
- Town ID: 6b110d52-9a70-4742-91d8-fab68a2bec3c
- Agent: Mayor (e920f2fe-6fce-4534-ae2e-43549fd8c66f)
- Rig ID: 905bf756-546a-484c-9b4e-1a0b6b903457
Recent Errors
Dispatch loop on triage batch beads — 23 failed in 41 minutes. Toast (polecat) consistently dispatched, fails, patrol creates next. Triage identity 403 on dispatch attempts.
Filed automatically by the Mayor via gt_report_bug.
What happened?
In town
6b110d52-9a70-4742-91d8-fab68a2bec3c(rignx.ts, id905bf756-546a-484c-9b4e-1a0b6b903457), the patrol service has been generating a new issue bead every ~60 seconds with titleTriage batch: N request(s)and bodyProcess all pending triage request beads and resolve each one.Each one is dispatched to a polecat (Toast, agent id
05563fc2-0404-4219-8e34-e2e88d657355), fails withdispatch_attemptshitting 5 within ~1 minute, and a new identical bead is created immediately by patrol.In a 41-minute window (11:31–12:12 UTC today, 2026-06-23), 23 such beads accumulated as
status=failed. After bulk-deleting them, more appeared within minutes.Root cause is likely: (a) patrol itself is healthy but every dispatch fails because the underlying triage identity has a 403 mismatch (separate escalation already filed), and (b) patrol has no back-off or dedup on failed-dispatch. So it spins forever.
Impact: dashboard is unreadable, mayor has to bulk-delete failed triage beads repeatedly, polecat compute is wasted.
Expected: patrol should stop creating new triage-batch beads if the previous N (e.g. 3) failed within a short window, or until the triage identity is repaired. Alternatively, patrol should back off exponentially.
Reproduction: log into town 6b110d52 dashboard, watch the
failedfilter over 5 minutes — at least 5 newTriage batch: N request(s)beads appear.Related: triage identity mismatch (403) escalation, separately reported.
Severity: medium. Not blocking work, but unusable dashboard.
Area
Agent Dispatch / Scheduling
Context
Recent Errors
Filed automatically by the Mayor via
gt_report_bug.