What happened?
In town 5e77618f-6c26-42d4-8c1a-1f09b2bd870b, rig "aircard" (bf584957-7ac3-44b9-820a-35a330b815f3), three control-plane anomalies caused incorrect remediation during an AeroDrop build:
-
gt_list_beads returns EMPTY transiently while a convoy is landing. While convoy 0a437da5 was actively landing (it eventually landed at 2026-06-16T09:26:26.903Z with 8/8 beads closed), gt_list_beads for the rig repeatedly returned "No beads found matching the filter." — including with no status filter, and with status=open/in_progress. gt_list_agents also returned "No agents registered" at the same moment. This made it appear all beads/agents were wiped, leading me to wrongly conclude the convoy broke and create a redundant convoy. The data was actually fine and the convoy landed moments later.
-
gt_bead_delete returns HTTP 404 "Bead not found" while ACTUALLY deleting. I deleted 8 bead IDs (e.g., def1588f-15dd-4a20-97e1-0f85903d33c3, 4ccdb71b-...) that existed seconds prior; all 8 calls returned 404, yet a subsequent gt_list_beads showed the beads were in fact removed. So the operation succeeded but reported failure. (Earlier in the same session, single-ID deletes of 6 other beads returned clean success messages, so the behavior is inconsistent.)
-
gt_bead_delete with bead_id as a JSON ARRAY of UUIDs returns the same 404 "Bead not found" and performs no bulk delete, even though the tool is documented to accept "a single UUID string or an array of UUIDs to bulk-delete up to 5000 at once". Only single-string IDs work.
These caused a redundant staged convoy to be created and then cleaned up. Flagging for investigation; happy to provide more IDs/timestamps.
Area
Bead Board / Dashboard
Context
- Town ID: 5e77618f-6c26-42d4-8c1a-1f09b2bd870b
- Agent: Mayor (92c22b02-c5f5-4b4e-97bd-b3017c7c65f1)
- Rig ID: bf584957-7ac3-44b9-820a-35a330b815f3
Recent Errors
Gastown API error (404): Bead not found (x8 on gt_bead_delete, despite beads being removed); "No beads found matching the filter." from gt_list_beads during convoy landing; "No agents registered in this rig." from gt_list_agents during the same window.
Filed automatically by the Mayor via gt_report_bug.
What happened?
In town 5e77618f-6c26-42d4-8c1a-1f09b2bd870b, rig "aircard" (bf584957-7ac3-44b9-820a-35a330b815f3), three control-plane anomalies caused incorrect remediation during an AeroDrop build:
gt_list_beads returns EMPTY transiently while a convoy is landing. While convoy 0a437da5 was actively landing (it eventually landed at 2026-06-16T09:26:26.903Z with 8/8 beads closed), gt_list_beads for the rig repeatedly returned "No beads found matching the filter." — including with no status filter, and with status=open/in_progress. gt_list_agents also returned "No agents registered" at the same moment. This made it appear all beads/agents were wiped, leading me to wrongly conclude the convoy broke and create a redundant convoy. The data was actually fine and the convoy landed moments later.
gt_bead_delete returns HTTP 404 "Bead not found" while ACTUALLY deleting. I deleted 8 bead IDs (e.g., def1588f-15dd-4a20-97e1-0f85903d33c3, 4ccdb71b-...) that existed seconds prior; all 8 calls returned 404, yet a subsequent gt_list_beads showed the beads were in fact removed. So the operation succeeded but reported failure. (Earlier in the same session, single-ID deletes of 6 other beads returned clean success messages, so the behavior is inconsistent.)
gt_bead_delete with bead_id as a JSON ARRAY of UUIDs returns the same 404 "Bead not found" and performs no bulk delete, even though the tool is documented to accept "a single UUID string or an array of UUIDs to bulk-delete up to 5000 at once". Only single-string IDs work.
These caused a redundant staged convoy to be created and then cleaned up. Flagging for investigation; happy to provide more IDs/timestamps.
Area
Bead Board / Dashboard
Context
Recent Errors
Filed automatically by the Mayor via
gt_report_bug.