sirens-deep: failed turns produce no Discord response at all #138

New issue

Closed

opened 2026-08-12 09:40:20 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-12 09:40:20 +00:00

Member

Symptom

When a turn fails, Deep sends nothing. From the user's side a failed turn is indistinguishable from a bot that ignored them.

Evidence

In every failure trace examined, the root span is discord.receive with status_code: Error and no outbound message:

c698b4e3a5196b9281655117f802fb14 (08:07:06) — discord.receive ERROR "Turn processing failed." after 10.0s. Nothing sent.
883ba8968cd370c32d678168dbad68b5 (07:57:41) — 180s MCP hang, orphaned root span. Nothing sent.

Reported transcript, where three of seven messages got no reply and no acknowledgement of any kind:

can you create a fj issue -> <silence>
can you create a fj issue -> <silence>
???                      -> <silence>

Why this matters more than the individual failures

There are currently at least three independent failure modes that all terminate as silence:

validation:ungrounded_action_claim -> 502 (this repo, separate issue)
forgejo MCP hanging 180s (coilyco-flight-deck/ward-mcp, separate issue)
steam MCP returning 400 (separate issue)

Each one is individually diagnosable only from traces. A user cannot distinguish them, cannot tell a failure from being ignored, and has no signal to retry. Surfacing turn failure to the channel makes all three self-reporting and collapses the diagnostic cost.

Design notes

The message should not leak internals. Status class and a trace correlator are enough; the model's rejected output and MCP internals should not go to Discord.
Deep's turn failures include upstream 502s, validation rejections, and tool timeouts. These want distinguishable user-facing text, since the user's correct next action differs (retry vs. rephrase vs. wait).
A failure reply must not itself be able to fail silently — if the error path depends on the model, it inherits the bug.

Acceptance

A forced upstream failure produces a visible Discord message rather than silence.
The failure message is emitted without a model round trip.
The successful path is unchanged (ping -> pong).
No internal payloads, model output, or MCP details appear in the user-facing text.

Next owner

Engineer.

## Symptom When a turn fails, Deep sends nothing. From the user's side a failed turn is indistinguishable from a bot that ignored them. ## Evidence In every failure trace examined, the root span is `discord.receive` with `status_code: Error` and no outbound message: - `c698b4e3a5196b9281655117f802fb14` (08:07:06) — `discord.receive` ERROR "Turn processing failed." after 10.0s. Nothing sent. - `883ba8968cd370c32d678168dbad68b5` (07:57:41) — 180s MCP hang, orphaned root span. Nothing sent. Reported transcript, where three of seven messages got no reply and no acknowledgement of any kind: ``` can you create a fj issue -> <silence> can you create a fj issue -> <silence> ??? -> <silence> ``` ## Why this matters more than the individual failures There are currently at least three independent failure modes that all terminate as silence: 1. `validation:ungrounded_action_claim` -> 502 (this repo, separate issue) 2. forgejo MCP hanging 180s (`coilyco-flight-deck/ward-mcp`, separate issue) 3. steam MCP returning 400 (separate issue) Each one is individually diagnosable only from traces. A user cannot distinguish them, cannot tell a failure from being ignored, and has no signal to retry. Surfacing turn failure to the channel makes all three self-reporting and collapses the diagnostic cost. ## Design notes - The message should not leak internals. Status class and a trace correlator are enough; the model's rejected output and MCP internals should not go to Discord. - Deep's turn failures include upstream 502s, validation rejections, and tool timeouts. These want distinguishable user-facing text, since the user's correct next action differs (retry vs. rephrase vs. wait). - A failure reply must not itself be able to fail silently — if the error path depends on the model, it inherits the bug. ## Acceptance - A forced upstream failure produces a visible Discord message rather than silence. - The failure message is emitted without a model round trip. - The successful path is unchanged (`ping` -> `pong`). - No internal payloads, model output, or MCP details appear in the user-facing text. ## Next owner Engineer.

coilyco-ops referenced this issue from a commit

2026-08-12 10:11:17 +00:00

fix(turn): tell the member a turn failed instead of going silent

coilyco-ops closed this issue

2026-08-12 10:11:17 +00:00

coilyco-ops referenced this issue

2026-08-12 10:25:26 +00:00

One MCP tool call can consume the entire turn budget, because only connect and list are bounded #141

coilyco-ops referenced this issue from a commit

2026-08-12 10:32:29 +00:00

fix(mcp): bound one tool call so it cannot spend the whole turn

coilyco-ops referenced this issue