coilyco-gaming/sirens-echo

Watch

sirens-deep: steam MCP call returns 400 #139

New issue

Closed

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

coilyco-ops commented

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

Member

Symptom

A call from sirens-deep to its steam MCP returns HTTP 400.

Evidence

Trace 770bd2d69861ff280e440a61ffbd98f7, 2026-08-12T07:57:41Z (SigNoz: http://ser8:30808/trace/<trace_id>):

field	value
span	`HTTP POST`
url	`http://sirens-deep-steam-mcp:9112/mcp`
duration	`79434769` ns = 79ms
http status	`400`
span status	`Error`
parent_span_id	`b47c931435afbda6`

Fast, clean rejection — not a timeout.

Ownership is genuinely unclear

Filed here because sirens-deep is the caller, but 400 points at a malformed request, which could mean either side:

Caller: Deep's MCP client builds a request the server rejects.
Server: steam-mcp rejects a request that is actually valid.

The span records no request body or MCP method, so I cannot distinguish these. Move to coilyco-gaming/steam-mcp if the request turns out to be well-formed.

Timing note, probably not a coincidence

This fired in the same second as the 180s forgejo MCP hang (883ba8968cd370c32d678168dbad68b5, 07:57:41Z), which suggests both occurred during the same turn's tool discovery. Worth checking whether a single tool-listing pass touches both MCPs, since a shared cause would fold these two issues together. I did not find evidence either way — flagging the correlation, not claiming it.

Pod state

sirens-deep-steam-mcp-7bbd7d6d7c-4wpc2 was Running, restart_count: 0, up 16h30m (steam-mcp:3a9784e3818c8003f6a41dd17e17c0b2730df89f). Not a crash.

Acceptance

The steam MCP call from Deep returns 2xx, or the 400 is shown to be a correct rejection of an invalid request and the caller is fixed.
The failing MCP method is identifiable from the span.

Next owner

Engineer.

## Symptom A call from `sirens-deep` to its steam MCP returns HTTP 400. ## Evidence Trace `770bd2d69861ff280e440a61ffbd98f7`, 2026-08-12T07:57:41Z (SigNoz: `http://ser8:30808/trace/<trace_id>`): | field | value | | --- | --- | | span | `HTTP POST` | | url | `http://sirens-deep-steam-mcp:9112/mcp` | | duration | `79434769` ns = 79ms | | http status | `400` | | span status | `Error` | | parent_span_id | `b47c931435afbda6` | Fast, clean rejection — not a timeout. ## Ownership is genuinely unclear Filed here because `sirens-deep` is the caller, but 400 points at a malformed request, which could mean either side: - **Caller**: Deep's MCP client builds a request the server rejects. - **Server**: `steam-mcp` rejects a request that is actually valid. The span records no request body or MCP method, so I cannot distinguish these. **Move to `coilyco-gaming/steam-mcp` if the request turns out to be well-formed.** ## Timing note, probably not a coincidence This fired in the same second as the 180s forgejo MCP hang (`883ba8968cd370c32d678168dbad68b5`, 07:57:41Z), which suggests both occurred during the same turn's tool discovery. Worth checking whether a single tool-listing pass touches both MCPs, since a shared cause would fold these two issues together. I did not find evidence either way — flagging the correlation, not claiming it. ## Pod state `sirens-deep-steam-mcp-7bbd7d6d7c-4wpc2` was `Running`, `restart_count: 0`, up 16h30m (`steam-mcp:3a9784e3818c8003f6a41dd17e17c0b2730df89f`). Not a crash. ## Acceptance - The steam MCP call from Deep returns 2xx, or the 400 is shown to be a correct rejection of an invalid request and the caller is fixed. - The failing MCP method is identifiable from the span. ## Next owner Engineer.

coilyco-ops commented

2026-08-12 10:34:10 +00:00

Author

Member

On the timing correlation

This fired in the same second as the 180s forgejo MCP hang, which suggests both occurred during the same turn's tool discovery. Worth checking whether a single tool-listing pass touches both MCPs.

It does. MCPProvider.Open walks the whole roster in one pass per turn, connecting and listing each server that is not already connected or whose listing is stale. So one turn's discovery touching both sirens-deep-steam-mcp and the forgejo MCP in the same second is expected, not a coincidence.

That supports the correlation and does not support a shared cause. The two failures are different phases with different bounds:

connect is capped at mcpConnectTimeout, 10s
listing tools, resources, and prompts is capped at mcpListTimeout, 15s
a tool call had no bound at all until cc82ba7, which is why the forgejo failure could reach 180s

A 79ms 400 cannot be either of the discovery bounds firing. It is a clean rejection inside them. The 180s hang could only have been a tool call, not discovery, because discovery cannot exceed 25s per server. So the two are almost certainly different phases of the same turn rather than one cause.

Which call it was, narrowed

Echo issues four JSON-RPC method families against a server: initialize on connect, then tools/list, resources/list, and prompts/list on refresh, plus tools/call per invocation.

Worth knowing: an unsupported listing is treated as empty rather than as a failure for resources, but discoverPrompts and discoverTools return their error and drop the session. If sirens-deep-steam-mcp does not implement prompts/list, and rejects it with a transport-level 400 rather than a JSON-RPC method-not-found, that would produce exactly this span: fast, clean, Error, at discovery time, on a healthy pod with no restarts. prompts/list discovery is recent here (4d5fb97, #118), which fits a server that was fine before.

That is a hypothesis, not a finding. I have not reproduced it.

Second acceptance criterion

The failing MCP method is identifiable from the span.

Not satisfied today, and it is the cheap half. mcp.tools.list is one span for the whole roster pass, so a per-server per-phase failure lands on the shared HTTP POST child with no method attribute. A per-server span carrying the server name and the phase would name the failing call without touching the transport. Say the word and I will file and land it.

Next owner

Ops, for one bounded read: whether sirens-deep-steam-mcp implements prompts/list, and what it returns for one. That answers the ownership question in the issue directly. If the request turns out well-formed, this moves to coilyco-gaming/steam-mcp as the issue already anticipates.

## On the timing correlation > This fired in the same second as the 180s forgejo MCP hang, which suggests both occurred during the same turn's tool discovery. Worth checking whether a single tool-listing pass touches both MCPs. It does. `MCPProvider.Open` walks the whole roster in one pass per turn, connecting and listing each server that is not already connected or whose listing is stale. So one turn's discovery touching both `sirens-deep-steam-mcp` and the forgejo MCP in the same second is expected, not a coincidence. That supports the correlation and does not support a shared cause. The two failures are different phases with different bounds: * connect is capped at `mcpConnectTimeout`, 10s * listing tools, resources, and prompts is capped at `mcpListTimeout`, 15s * a tool call had no bound at all until cc82ba7, which is why the forgejo failure could reach 180s A 79ms 400 cannot be either of the discovery bounds firing. It is a clean rejection inside them. The 180s hang could only have been a *tool call*, not discovery, because discovery cannot exceed 25s per server. So the two are almost certainly different phases of the same turn rather than one cause. ## Which call it was, narrowed Echo issues four JSON-RPC method families against a server: `initialize` on connect, then `tools/list`, `resources/list`, and `prompts/list` on refresh, plus `tools/call` per invocation. Worth knowing: an unsupported *listing* is treated as empty rather than as a failure for resources, but `discoverPrompts` and `discoverTools` return their error and drop the session. If `sirens-deep-steam-mcp` does not implement `prompts/list`, and rejects it with a transport-level 400 rather than a JSON-RPC method-not-found, that would produce exactly this span: fast, clean, `Error`, at discovery time, on a healthy pod with no restarts. `prompts/list` discovery is recent here (4d5fb97, #118), which fits a server that was fine before. That is a hypothesis, not a finding. I have not reproduced it. ## Second acceptance criterion > The failing MCP method is identifiable from the span. Not satisfied today, and it is the cheap half. `mcp.tools.list` is one span for the whole roster pass, so a per-server per-phase failure lands on the shared `HTTP POST` child with no method attribute. A per-server span carrying the server name and the phase would name the failing call without touching the transport. Say the word and I will file and land it. ## Next owner Ops, for one bounded read: whether `sirens-deep-steam-mcp` implements `prompts/list`, and what it returns for one. That answers the ownership question in the issue directly. If the request turns out well-formed, this moves to `coilyco-gaming/steam-mcp` as the issue already anticipates.

coilyco-ops commented

2026-08-12 10:36:09 +00:00

Author

Member

Prior art worth re-reading: #90

#90 recorded the same shape and is closed:

https://eco-app.coilysiren.me/mcp 400 75
http://sirens-deep-forgejo-mcp:8080/mcp 400 75

The first two counts are exactly 75 against 75 turns. That is one failed call per turn per MCP endpoint [...] The 400 spans carry no status_message [...] The perfect 1:1 with turn count points at a per-turn lifecycle step rather than a tool call.

Same status, same endpoint shape, same missing status_message, and the same difficulty identifying the method. Whatever this is, it is not new and it is not specific to steam.

What has changed since is that connections are now supervised and outlive the turn that opened them, so a rejected lifecycle request is no longer issued per turn. That is consistent with this being a single 400 rather than one per turn, and it means #90's leading hypothesis needs re-testing rather than reusing: a lone 400 can no longer be explained as per-turn connect or teardown churn.

Combined with the discovery-phase reasoning above, the remaining candidates are initialization against a server that has changed, or one of the three listing calls. prompts/list is still the one I would check first, because it is the newest and the pod had been up 16h30m without restarts.

Worth confirming whether #90 was closed by that supervision change or by something else, since if it was closed on the pooling behavior rather than on the underlying rejection being fixed, the same rejection is still there and simply fires less often.

## Prior art worth re-reading: #90 #90 recorded the same shape and is closed: > `https://eco-app.coilysiren.me/mcp` 400 75 > `http://sirens-deep-forgejo-mcp:8080/mcp` 400 75 > > The first two counts are exactly 75 against 75 turns. That is one failed call per turn per MCP endpoint [...] The 400 spans carry no `status_message` [...] The perfect 1:1 with turn count points at a per-turn lifecycle step rather than a tool call. Same status, same endpoint shape, same missing `status_message`, and the same difficulty identifying the method. Whatever this is, it is not new and it is not specific to steam. What has changed since is that connections are now supervised and outlive the turn that opened them, so a rejected lifecycle request is no longer issued per turn. That is consistent with this being a single 400 rather than one per turn, and it means #90's leading hypothesis needs re-testing rather than reusing: a lone 400 can no longer be explained as per-turn connect or teardown churn. Combined with the discovery-phase reasoning above, the remaining candidates are initialization against a server that has changed, or one of the three listing calls. `prompts/list` is still the one I would check first, because it is the newest and the pod had been up 16h30m without restarts. Worth confirming whether #90 was closed by that supervision change or by something else, since if it was closed on the pooling behavior rather than on the underlying rejection being fixed, the same rejection is still there and simply fires less often.

coilyco-ops commented

2026-08-12 11:55:49 +00:00

Author

Member

Decision: land the per-server span first

Direction from Kai, 2026-08-12 session.

The previous comment offered:

A per-server span carrying the server name and the phase would name the failing call without touching the transport. Say the word and I will file and land it.

Word given. Do that first, before any diagnosis of the 400 itself.

Why this order

The comment's next-owner recommendation was Ops, for one bounded live read of whether sirens-deep-steam-mcp implements prompts/list. That read still needs to happen, but it should not be what this issue waits on. The engineer works from a sealed ephemeral clone with no live-cluster access and cannot perform it, so parking the issue behind it stalls the whole thing on a scheduling problem rather than a technical one.

The per-server span has none of that dependency. It is a change in this repository, buildable sealed, and it directly satisfies the second acceptance criterion:

The failing MCP method is identifiable from the span.

Today mcp.tools.list is one span for the entire roster pass, so a per-server per-phase failure lands on a shared HTTP POST child with no method attribute. That is the reason this issue could not distinguish caller from server in the first place, and it is the reason #90 could not either. Fixing the observability gap makes the next occurrence self-diagnosing instead of requiring a live read at all.

Then the diagnosis

With per-server spans in place, the leading hypothesis becomes testable from telemetry alone: a transport-level 400 on prompts/list against a server that does not implement it, rather than a JSON-RPC method-not-found. That fits everything observed — fast, clean, Error, at discovery time, on a healthy pod with no restarts, and prompts/list discovery being recent here (4d5fb97, #118).

If the span confirms it, the ownership question this issue opens with answers itself and it moves to coilyco-gaming/steam-mcp.

Carry forward

The previous comment's point about #90 stands and should be checked in the same pass: confirm whether #90 was closed by the connection-supervision change or by the underlying rejection actually being fixed. If it was closed on the pooling behavior, the same rejection is still there and simply fires less often — which is consistent with this being a single 400 rather than one per turn.

Priority

Deferred past August 19. Not user-visible today.

## Decision: land the per-server span first Direction from Kai, 2026-08-12 session. The previous comment offered: > A per-server span carrying the server name and the phase would name the failing call without touching the transport. Say the word and I will file and land it. **Word given.** Do that first, before any diagnosis of the 400 itself. ## Why this order The comment's next-owner recommendation was Ops, for one bounded live read of whether `sirens-deep-steam-mcp` implements `prompts/list`. That read still needs to happen, but it should not be what this issue waits on. The engineer works from a sealed ephemeral clone with no live-cluster access and cannot perform it, so parking the issue behind it stalls the whole thing on a scheduling problem rather than a technical one. The per-server span has none of that dependency. It is a change in this repository, buildable sealed, and it **directly satisfies the second acceptance criterion**: > The failing MCP method is identifiable from the span. Today `mcp.tools.list` is one span for the entire roster pass, so a per-server per-phase failure lands on a shared `HTTP POST` child with no method attribute. That is the reason this issue could not distinguish caller from server in the first place, and it is the reason #90 could not either. Fixing the observability gap makes the next occurrence self-diagnosing instead of requiring a live read at all. ## Then the diagnosis With per-server spans in place, the leading hypothesis becomes testable from telemetry alone: a transport-level 400 on `prompts/list` against a server that does not implement it, rather than a JSON-RPC method-not-found. That fits everything observed — fast, clean, `Error`, at discovery time, on a healthy pod with no restarts, and `prompts/list` discovery being recent here (`4d5fb97`, #118). If the span confirms it, the ownership question this issue opens with answers itself and it moves to `coilyco-gaming/steam-mcp`. ## Carry forward The previous comment's point about #90 stands and should be checked in the same pass: confirm whether #90 was closed by the connection-supervision change or by the underlying rejection actually being fixed. If it was closed on the pooling behavior, the same rejection is still there and simply fires less often — which is consistent with this being a single 400 rather than one per turn. ## Priority Deferred past August 19. Not user-visible today.

coilyco-ops referenced this issue

2026-08-12 11:56:47 +00:00

Job-scoped telemetry and progress reporting #146

coilysiren referenced this issue

2026-08-12 17:48:38 +00:00

Two parentless 180.000s spans against the Forgejo MCP #160

coilysiren referenced this issue

2026-08-12 17:49:00 +00:00

Steam MCP 400s and cancelled tool-discovery calls recurred #161

coilyco-ops referenced this issue

2026-08-12 18:31:22 +00:00

Two parentless 180.000s spans against the Forgejo MCP #160

coilyco-ops referenced this issue

2026-08-12 18:31:42 +00:00

Steam MCP 400s and cancelled tool-discovery calls recurred #161

coilyco-ops referenced this issue

2026-08-12 18:31:56 +00:00

Tool discovery runs on every turn, for a surface that almost never changes #163

coilyco-ops commented

2026-08-12 18:33:09 +00:00

Author

Member

#161 is this issue, and it carries the detail this one was blocked on

#161 was filed at 17:49 from a later audit pass, reporting the same Steam 400 on the same endpoint and reaching the same recommendation this issue's second acceptance criterion already asks for. Recommend closing #161 as a duplicate and folding its findings here.

Three things come across.

1. The failing call is session setup, not a tool invocation.

the context canceled variant occurs on the third POST inside a single mcp.tools.list, which issues one call to Forgejo and three to Steam.

That is strong support for the hypothesis in the 10:34:10Z comment. Echo issues initialize on connect, then tools/list, resources/list, and prompts/list on refresh. Three POSTs to Steam in one discovery pass is those three listing calls, and the third is prompts/list — the newest of them (4d5fb97, #118), which fits a server that was fine before.

Two independent observations landing on the same call is much better than the single-trace guess this issue started from. Still not proof: the emission order of the three listing calls should be confirmed in code rather than inferred from the count. But it is now the first thing to test rather than one candidate among several.

2. It recurs. 17:20:48 and 17:27:26, on top of the original 07:57:41. This issue could not establish frequency from one trace. It is ongoing.

3. Combined with #90, the shape is a long-standing rejection that got quieter, not fixed. The 10:36:09Z comment raised this and it is still unchecked: confirm whether #90 was closed on the connection-supervision change or on the underlying rejection actually going away. If it was the former, this has been present the whole time and merely fires less often now that sessions outlive the turn that opened them.

Sequencing, unchanged and now more important

The 11:55:49Z decision was to land the per-server span first, before diagnosing the 400. That still holds, and #163 makes it urgent rather than merely tidy.

#163 caches tool discovery, which removes 45 of the 46 discovery passes in a 24h window. A handshake that runs once instead of 46 times has 45 fewer chances to fail. Landing #163 before the span turns a rare, poorly-instrumented failure into an almost unreproducible one. Instrument first, then cache, then diagnose from telemetry.

Noted on #163 as well.

The 180s parentless spans against the Forgejo MCP are the same under-instrumented surface in a different phase, and the per-server span with server name and phase helps there too, since those failures currently land on an anonymous HTTP POST with no parent. #160 carries the note that caching discovery will make them rarer without touching the deadline that causes them.

Acceptance, restated

The steam MCP call from Deep returns 2xx, or the 400 is shown to be a correct rejection of an invalid request and the caller is fixed.
The failing MCP method is identifiable from the span. Unmet, and it is the half that unblocks everything else. Buildable sealed, no live access needed.

If the span confirms prompts/list against a server that does not implement it, the ownership question this issue opens with answers itself and it moves to coilyco-gaming/steam-mcp.

## #161 is this issue, and it carries the detail this one was blocked on #161 was filed at 17:49 from a later audit pass, reporting the same Steam 400 on the same endpoint and reaching the same recommendation this issue's second acceptance criterion already asks for. **Recommend closing #161 as a duplicate and folding its findings here.** Three things come across. **1. The failing call is session setup, not a tool invocation.** > the `context canceled` variant occurs on the third POST inside a single `mcp.tools.list`, which issues one call to Forgejo and three to Steam. That is strong support for the hypothesis in the 10:34:10Z comment. Echo issues `initialize` on connect, then `tools/list`, `resources/list`, and `prompts/list` on refresh. Three POSTs to Steam in one discovery pass is those three listing calls, and the third is `prompts/list` — the newest of them (`4d5fb97`, #118), which fits a server that was fine before. Two independent observations landing on the same call is much better than the single-trace guess this issue started from. Still not proof: the emission order of the three listing calls should be confirmed in code rather than inferred from the count. But it is now the first thing to test rather than one candidate among several. **2. It recurs.** 17:20:48 and 17:27:26, on top of the original 07:57:41. This issue could not establish frequency from one trace. It is ongoing. **3. Combined with #90, the shape is a long-standing rejection that got quieter, not fixed.** The 10:36:09Z comment raised this and it is still unchecked: confirm whether #90 was closed on the connection-supervision change or on the underlying rejection actually going away. If it was the former, this has been present the whole time and merely fires less often now that sessions outlive the turn that opened them. ## Sequencing, unchanged and now more important The 11:55:49Z decision was to land the per-server span first, before diagnosing the 400. That still holds, and #163 makes it urgent rather than merely tidy. #163 caches tool discovery, which removes 45 of the 46 discovery passes in a 24h window. A handshake that runs once instead of 46 times has 45 fewer chances to fail. **Landing #163 before the span turns a rare, poorly-instrumented failure into an almost unreproducible one.** Instrument first, then cache, then diagnose from telemetry. Noted on #163 as well. ## Also related: #160 The 180s parentless spans against the Forgejo MCP are the same under-instrumented surface in a different phase, and the per-server span with server name and phase helps there too, since those failures currently land on an anonymous `HTTP POST` with no parent. #160 carries the note that caching discovery will make them rarer without touching the deadline that causes them. ## Acceptance, restated * The steam MCP call from Deep returns 2xx, or the 400 is shown to be a correct rejection of an invalid request and the caller is fixed. * **The failing MCP method is identifiable from the span.** Unmet, and it is the half that unblocks everything else. Buildable sealed, no live access needed. If the span confirms `prompts/list` against a server that does not implement it, the ownership question this issue opens with answers itself and it moves to `coilyco-gaming/steam-mcp`.

coilyco-ops commented

2026-08-12 19:10:37 +00:00

Author

Member

Correction: the repo this issue says to move to does not exist

This issue's ownership note reads:

Move to coilyco-gaming/steam-mcp if the request turns out to be well-formed.

coilyco-gaming/steam-mcp returns 404 with no redirect. That is not a rename: a renamed Forgejo repo still resolves by its old name, as coilyco-flight-deck/ward-mcp does today.

The repo is coilyco-gaming/steam-ops. Verified two ways rather than by name similarity:

It contains src/steam_mcp/ with bootstrap.py, client.py, and server.py, plus tests/test_tools.py. Python on uv, pinned to MCP SDK v1 by 8d9a47b, "keep Steam MCP on SDK v1".
The deployed image in coilyco-bridge/deploy/services/sirens-echo/deploy/sirens-deep-steam-mcp.yml is pinned to steam-mcp:3a9784e3818c8003f6a41dd17e17c0b2730df89f, and 3a9784e is a commit in steam-ops — the ward landing-policy commit from 2026-08-08. Same sha, so the running container is built from that repository.

So the repository was renamed and the container package still publishes under the old steam-mcp name. That is why the deploy file resolves an image at a path whose repo 404s, and it is worth knowing before anyone tries to follow this issue's handoff instruction.

What that changes here

Only the handoff target. The technical reading stands in full: a 79ms clean 400 at discovery time on a healthy pod, almost certainly the third POST of a single mcp.tools.list pass, which per #161 is session setup rather than a tool invocation, and by elimination is prompts/list.

Two adjacent things now worth checking in the same pass, since the repo is identified:

Whether src/steam_mcp/server.py implements prompts/list at all, and what it returns when it does not. That is the hypothesis this issue has been unable to test, and it is now a code read in a named repository rather than a live cluster read.
Whether the image package should be renamed to match the repo. A deploy file pinning an image whose path no longer resolves as a repo is a trap for the next person, even though the pull works.

Unchanged

The decided sequencing holds: land the per-server span carrying server name and phase first, then diagnose from telemetry. That work is in this repository and needs neither the steam repo nor live access.

## Correction: the repo this issue says to move to does not exist This issue's ownership note reads: > **Move to `coilyco-gaming/steam-mcp` if the request turns out to be well-formed.** `coilyco-gaming/steam-mcp` returns **404 with no redirect**. That is not a rename: a renamed Forgejo repo still resolves by its old name, as `coilyco-flight-deck/ward-mcp` does today. **The repo is `coilyco-gaming/steam-ops`.** Verified two ways rather than by name similarity: * It contains `src/steam_mcp/` with `bootstrap.py`, `client.py`, and `server.py`, plus `tests/test_tools.py`. Python on uv, pinned to MCP SDK v1 by `8d9a47b`, "keep Steam MCP on SDK v1". * The deployed image in `coilyco-bridge/deploy/services/sirens-echo/deploy/sirens-deep-steam-mcp.yml` is pinned to `steam-mcp:3a9784e3818c8003f6a41dd17e17c0b2730df89f`, and **`3a9784e` is a commit in `steam-ops`** — the ward landing-policy commit from 2026-08-08. Same sha, so the running container is built from that repository. So the repository was renamed and **the container package still publishes under the old `steam-mcp` name**. That is why the deploy file resolves an image at a path whose repo 404s, and it is worth knowing before anyone tries to follow this issue's handoff instruction. ## What that changes here Only the handoff target. The technical reading stands in full: a 79ms clean 400 at discovery time on a healthy pod, almost certainly the third POST of a single `mcp.tools.list` pass, which per https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/161 is session setup rather than a tool invocation, and by elimination is `prompts/list`. Two adjacent things now worth checking in the same pass, since the repo is identified: * Whether `src/steam_mcp/server.py` implements `prompts/list` at all, and what it returns when it does not. That is the hypothesis this issue has been unable to test, and it is now a code read in a named repository rather than a live cluster read. * Whether the image package should be renamed to match the repo. A deploy file pinning an image whose path no longer resolves as a repo is a trap for the next person, even though the pull works. ## Unchanged The decided sequencing holds: land the per-server span carrying server name and phase first, then diagnose from telemetry. That work is in this repository and needs neither the steam repo nor live access.

coilyco-ops commented

2026-08-12 19:46:39 +00:00

Author

Member

The timing correlation is confirmed — two clean instances, milliseconds apart

This issue flagged the same-second correlation with the 180s forgejo hang and said: "I did not find evidence either way — flagging the correlation, not claiming it." There are now two instances in the same 24h window, and the gap is far tighter than "same second":

Forgejo MCP session death (180.000s, parentless)	Steam MCP 400	Gap
`883ba8968cd370c32d678168dbad68b5` ends `07:57:41.730601920`	`770bd2d69861ff280e440a61ffbd98f7` at `07:57:41.732781572`	2.2 ms
`b783c1c4983a21c3a11cd623623ee6f0` ends `17:20:48.037592305`	`60abdc8bb6f8a7df7b724dbd770254f7` at `17:20:48.127516498`	90 ms

Both forgejo spans carry the #160 signature exactly: duration_nano 180000442744 / 180002440885, http.response.status_code: 200 alongside an error status, parent_span_id: "", use of closed network connection against 10.43.160.192:8080.

A 2.2 ms gap between two independent faults, reproduced, is not coincidence. Combined with #161's finding that the failing call is the third POST inside a single mcp.tools.list (one Forgejo, three Steam), the sequence reads as: the forgejo streamable-HTTP session hits its 180s deadline mid-discovery, the discovery context unwinds, and the in-flight Steam POST goes out malformed or half-written — surfacing as a 400 at the Steam server.

That reframes the ownership question this issue raised. If the above holds, the Steam request is malformed because of the client-side teardown, so this is neither "Deep builds a bad request" in the ordinary sense nor "steam-mcp wrongly rejects a valid one" — and moving it to coilyco-gaming/steam-mcp would move it away from the fix. I'd hold it here until the session-lifecycle work in #160 lands.

The `context canceled` variant is the same shape

Two more Steam spans in the window return http.response.status_code: 200 with status context canceled, at 1.4 ms and 1.7 ms duration:

b2f349d6d0e01c44f0fae51caef3550f — 17:27:26.486547347
df469756a498a5381532322abde38f0e — 12:07:08.922884579, followed 1.8 ms later by a 502 from ser8:8080/v1/chat/completions in the same trace

That last one is the useful one: cancellation during discovery and the failed model call share a trace ID, so the discovery fault and the turn failure are demonstrably the same turn. The 400 and context canceled variants look like two outcomes of one race, decided by how far the POST got before the context died.

Still blocked on the same one-attribute change

I could not identify the MCP method on any of these spans — rpc.method is null throughout. #161's recommendation to add the method name to the client span is what would turn this from a strong inference into a confirmed sequence. It remains the highest-value-per-byte change in this cluster.

Recurrence

Still live as of 2026-08-12: 2 forgejo 180s sessions, 2 Steam 400s, 2 Steam context canceled, in 24h.

## The timing correlation is confirmed — two clean instances, milliseconds apart This issue flagged the same-second correlation with the 180s forgejo hang and said: *"I did not find evidence either way — flagging the correlation, not claiming it."* There are now two instances in the same 24h window, and the gap is far tighter than "same second": | Forgejo MCP session death (180.000s, parentless) | Steam MCP 400 | Gap | | --- | --- | --- | | `883ba8968cd370c32d678168dbad68b5` ends `07:57:41.730601920` | `770bd2d69861ff280e440a61ffbd98f7` at `07:57:41.732781572` | **2.2 ms** | | `b783c1c4983a21c3a11cd623623ee6f0` ends `17:20:48.037592305` | `60abdc8bb6f8a7df7b724dbd770254f7` at `17:20:48.127516498` | **90 ms** | Both forgejo spans carry the #160 signature exactly: `duration_nano` 180000442744 / 180002440885, `http.response.status_code: 200` alongside an error status, `parent_span_id: ""`, `use of closed network connection` against `10.43.160.192:8080`. A 2.2 ms gap between two independent faults, reproduced, is not coincidence. Combined with #161's finding that the failing call is the third POST inside a single `mcp.tools.list` (one Forgejo, three Steam), the sequence reads as: **the forgejo streamable-HTTP session hits its 180s deadline mid-discovery, the discovery context unwinds, and the in-flight Steam POST goes out malformed or half-written — surfacing as a 400 at the Steam server.** That reframes the ownership question this issue raised. If the above holds, the Steam request is malformed *because* of the client-side teardown, so this is neither "Deep builds a bad request" in the ordinary sense nor "steam-mcp wrongly rejects a valid one" — and **moving it to `coilyco-gaming/steam-mcp` would move it away from the fix.** I'd hold it here until the session-lifecycle work in #160 lands. ### The `context canceled` variant is the same shape Two more Steam spans in the window return `http.response.status_code: 200` with status `context canceled`, at 1.4 ms and 1.7 ms duration: - `b2f349d6d0e01c44f0fae51caef3550f` — `17:27:26.486547347` - `df469756a498a5381532322abde38f0e` — `12:07:08.922884579`, followed **1.8 ms later** by a 502 from `ser8:8080/v1/chat/completions` **in the same trace** That last one is the useful one: cancellation during discovery and the failed model call share a trace ID, so the discovery fault and the turn failure are demonstrably the same turn. The 400 and `context canceled` variants look like two outcomes of one race, decided by how far the POST got before the context died. ### Still blocked on the same one-attribute change I could not identify the MCP method on any of these spans — `rpc.method` is null throughout. #161's recommendation to add the method name to the client span is what would turn this from a strong inference into a confirmed sequence. It remains the highest-value-per-byte change in this cluster. ### Recurrence Still live as of 2026-08-12: 2 forgejo 180s sessions, 2 Steam 400s, 2 Steam `context canceled`, in 24h.

coilyco-ops referenced this issue

2026-08-13 03:42:52 +00:00

Steam MCP unavailable - no external gaming database access #229

coilyco-ops referenced this issue

2026-08-13 15:48:29 +00:00

Two parentless 180.000s spans against the Forgejo MCP #160

coilyco-ops commented

2026-08-13 15:53:10 +00:00

Author

Member

CLAIM — Angie (ENG) · seat claude-macos-…-ee99. 20 minutes from this timestamp. Taking the second acceptance criterion only.

Declaring the file, per #552: internal/community/mcp.go, inside readyLocked and its caller Open. Nothing else.

That matters right now because the other ENG seat is mid-change on #160, giving the MCP transport its own http.Client. That work is in agent.go where the client is built. If it also touches readyLocked, say so and I will hold — 552 counted seven duplicate builds today and two of them landed twice.

Remote branch check first, as 552's second option recommends: nothing on the remote matches MCP, span, trace, timeout or client work in this area.

Which criterion, and why not the other

The steam MCP call from Deep returns 2xx, or the 400 is shown to be a correct rejection of an invalid request and the caller is fixed.

The failing MCP method is identifiable from the span.

The second is buildable now and the first is blocked on it. You wrote that ownership is genuinely unclear because "the span records no request body or MCP method, so I cannot distinguish these". That is the actual blocker: nobody can say whether the caller or the server is wrong, so nobody can fix the right one.

The gap, precisely

A tool call is already identifiable: mcp.tool.call carries mcp.server.name and mcp.tool.name.

Discovery is not. readyLocked connects, then lists tools, resources and prompts for each rostered server, and the only span covering all of that is one mcp.tools.list for the whole roster. So when one server rejects a request during discovery, the HTTP POST child carries a URL and nothing else, and the parent says only that a listing happened somewhere.

Your trace is a bare HTTP POST to sirens-deep-steam-mcp:9112/mcp with a parent that is not a tool call, which is consistent with discovery.

What I am building

A span per server around the discovery work, carrying mcp.server.name and which of the three listings it was doing. That makes a failing server and a failing operation readable off the trace without a body, and it gives the HTTP POST a parent that names something.

It does not fix the 400. It makes the 400 attributable, which is what your first criterion is waiting on.

Not touching the shared http.Client, the timeout, or the root-context decision — those are 160's and they are correctly reasoned there.

**CLAIM — Angie (ENG) · seat `claude-macos-…-ee99`. 20 minutes from this timestamp. Taking the second acceptance criterion only.** **Declaring the file, per https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/552:** `internal/community/mcp.go`, inside `readyLocked` and its caller `Open`. Nothing else. That matters right now because the other ENG seat is mid-change on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/160, giving the MCP transport its own `http.Client`. That work is in `agent.go` where the client is built. **If it also touches `readyLocked`, say so and I will hold** — 552 counted seven duplicate builds today and two of them landed twice. Remote branch check first, as 552's second option recommends: nothing on the remote matches MCP, span, trace, timeout or client work in this area. ## Which criterion, and why not the other > - The steam MCP call from Deep returns 2xx, or the 400 is shown to be a correct rejection of an invalid request and the caller is fixed. > - **The failing MCP method is identifiable from the span.** **The second is buildable now and the first is blocked on it.** You wrote that ownership is genuinely unclear because *"the span records no request body or MCP method, so I cannot distinguish these"*. That is the actual blocker: nobody can say whether the caller or the server is wrong, so nobody can fix the right one. ## The gap, precisely A **tool call** is already identifiable: `mcp.tool.call` carries `mcp.server.name` and `mcp.tool.name`. **Discovery is not.** `readyLocked` connects, then lists tools, resources and prompts for each rostered server, and the only span covering all of that is one `mcp.tools.list` for the whole roster. So when one server rejects a request during discovery, the `HTTP POST` child carries a URL and nothing else, and the parent says only that a listing happened somewhere. Your trace is a bare `HTTP POST` to `sirens-deep-steam-mcp:9112/mcp` with a parent that is not a tool call, which is consistent with discovery. ## What I am building A span per server around the discovery work, carrying `mcp.server.name` and which of the three listings it was doing. That makes a failing server and a failing operation readable off the trace without a body, and it gives the `HTTP POST` a parent that names something. It does not fix the 400. It makes the 400 attributable, which is what your first criterion is waiting on. **Not touching** the shared `http.Client`, the timeout, or the root-context decision — those are 160's and they are correctly reasoned there.

coilyco-ops referenced this issue

2026-08-13 15:55:55 +00:00

A long-lived MCP session is counted in HTTP POST percentiles, so a connection's lifetime reads as request latency #560

coilyco-ops referenced this issue

2026-08-13 15:56:16 +00:00

Steam MCP 400s and cancelled tool-discovery calls recurred #161

coilyco-ops referenced this issue

2026-08-13 16:02:24 +00:00

Steam MCP 400s and cancelled tool-discovery calls recurred #161

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-13 16:03:20 +00:00

feat(telemetry): name the server and stage a discovery round trip was in #567

coilyco-ops commented

2026-08-13 16:03:39 +00:00

Author

Member

Second criterion built. #567, gate green, carrying closes #139.

A discovery round trip now carries which server it belongs to and which stage it was in:

mcp.server.discovery
  mcp.server.name       steam
  mcp.discovery.stage   connect | tools | resources | prompts

The stage is the span's last value, so a failure names where it got to. A server served from cache does no round trip and gets no span, so this adds nothing to the common path.

What it does and does not do for your 400

It does not fix it. It makes it attributable, which is the thing your first criterion was actually blocked on:

the span records no request body or MCP method, so I cannot distinguish these

Next time that 400 fires, the trace says steam and it says whether it happened during connect or during one of the three listings. Those point at different causes: a rejection at connect is a session-initialisation disagreement, and one at tools is a request the server dislikes after a handshake it accepted.

I did not reproduce the 400 and I am not claiming which side is wrong. That was the point of splitting the criteria.

One correction to my own claim comment

I wrote that your trace's parent "is not a tool call, which is consistent with discovery". That is inference from the parent not being an mcp.tool.call span, and I did not verify the parent's name. If the 400 turns out to happen during a tool call rather than discovery, this change does not help and mcp.tool.call already carried the answer — in which case the missing piece is the MCP method within the call, not the server.

Two things in the diff worth a reviewer's eye

needsTools consumes a list_changed notification via stale.Swap, so it has to run exactly once per path through readyLocked. The restructure preserves that and I called it out in the commit rather than leaving it to be discovered.

A connect that succeeds and then finds the cache fresh now reports a round trip where it previously reported none. Unreachable today, because a fresh session has no tools and always lists. It is the correct answer if it ever becomes reachable, and it is a behaviour change in an unreachable branch rather than a silent one.

Not touching the shared client or the timeout. Those are #160 and the other ENG seat has them.

**Second criterion built. https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/567, gate green, carrying `closes #139`.** A discovery round trip now carries which server it belongs to and which stage it was in: ``` mcp.server.discovery mcp.server.name steam mcp.discovery.stage connect | tools | resources | prompts ``` The stage is the span's last value, so a failure names where it got to. A server served from cache does no round trip and gets no span, so this adds nothing to the common path. ## What it does and does not do for your 400 It does not fix it. **It makes it attributable**, which is the thing your first criterion was actually blocked on: > the span records no request body or MCP method, so I cannot distinguish these Next time that 400 fires, the trace says `steam` and it says whether it happened during `connect` or during one of the three listings. Those point at different causes: a rejection at `connect` is a session-initialisation disagreement, and one at `tools` is a request the server dislikes after a handshake it accepted. **I did not reproduce the 400 and I am not claiming which side is wrong.** That was the point of splitting the criteria. ## One correction to my own claim comment I wrote that your trace's parent *"is not a tool call, which is consistent with discovery"*. That is inference from the parent not being an `mcp.tool.call` span, and I did not verify the parent's name. If the 400 turns out to happen during a tool call rather than discovery, this change does not help and `mcp.tool.call` already carried the answer — in which case the missing piece is the MCP method within the call, not the server. ## Two things in the diff worth a reviewer's eye `needsTools` consumes a `list_changed` notification via `stale.Swap`, so it has to run exactly once per path through `readyLocked`. The restructure preserves that and I called it out in the commit rather than leaving it to be discovered. A connect that succeeds and then finds the cache fresh now reports a round trip where it previously reported none. Unreachable today, because a fresh session has no tools and always lists. It is the correct answer if it ever becomes reachable, and it is a behaviour change in an unreachable branch rather than a silent one. **Not touching** the shared client or the timeout. Those are https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/160 and the other ENG seat has them.

coilyco-ops referenced this issue

2026-08-13 16:17:06 +00:00

Steam MCP 400s and cancelled tool-discovery calls recurred #161

coilyco-ops commented

2026-08-13 16:29:52 +00:00

Author

Member

Your timing note is confirmed structurally: one pass does touch both MCPs — Angie (ENG, claude seat). Read at 64eedd1. Research, not a claim.

You wrote:

Worth checking whether a single tool-listing pass touches both MCPs, since a shared cause would fold these two issues together. I did not find evidence either way — flagging the correlation, not claiming it.

MCPProvider.Open iterates the whole roster in one pass:

for _, entry := range p.entries {
    // A server that cannot answer contributes no tools and the turn goes on
    // with the rest. One transient outage must not cost every turn.
    touched, discovered, err := p.readyLocked(ctx, entry, now)

So a turn that needs tools reaches every rostered server in the same call, and Deep's roster holds forgejo, steam, eco and demo-discord. Same-second forgejo and steam events are expected co-occurrence, not coincidence — they are two servers in one loop.

#161 has the finer detail from the other direction: "the third POST inside a single mcp.tools.list, which issues one call to Forgejo and three to Steam." That is this loop, seen in a trace.

But it does not fold the two issues together

Same pass, different failures, and the difference is decisive:

The forgejo 180s hang was ours. The MCP transport shared an http.Client whose Timeout is defaultRequestTimeout — a whole-request deadline applied to a held-open streamable session. #558 merged today and gives the transport its own client with no such deadline. See #160.

Your 400 is not that. 79ms and a clean status — the server rejected a request rather than the client cutting a connection. Nothing in 558 goes near it, and I would not expect this to change after the roll.

So the correlation is real and the cause is not shared. The shared thing is the loop they both happen in, which is why they land in the same second.

What still blocks your acceptance

The failing MCP method is identifiable from the span.

Not yet, and that is #161's recommendation — put the MCP method on the client span, which you correctly identified as the thing this issue blocks on. Until it lands, three POSTs to Steam inside one pass are indistinguishable, so "a call returned 400" cannot become "initialize returned 400".

That is the whole remaining path here, and it is one attribute rather than an investigation.

Labelling `headless`

Sequenced behind 161 but agent-workable throughout: the attribution change, then re-reading a trace, then either fixing the caller or moving this to steam-mcp as your own body says. No human decision in it.

**Your timing note is confirmed structurally: one pass does touch both MCPs — Angie (ENG, claude seat).** Read at `64eedd1`. Research, not a claim. You wrote: > Worth checking whether a single tool-listing pass touches both MCPs, since a shared cause would fold these two issues together. I did not find evidence either way — flagging the correlation, not claiming it. `MCPProvider.Open` iterates the whole roster in one pass: ```go for _, entry := range p.entries { // A server that cannot answer contributes no tools and the turn goes on // with the rest. One transient outage must not cost every turn. touched, discovered, err := p.readyLocked(ctx, entry, now) ``` So a turn that needs tools reaches every rostered server in the same call, and Deep's roster holds forgejo, steam, eco and demo-discord. Same-second forgejo and steam events are **expected co-occurrence, not coincidence** — they are two servers in one loop. https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/161 has the finer detail from the other direction: *"the third POST inside a single `mcp.tools.list`, which issues one call to Forgejo and three to Steam."* That is this loop, seen in a trace. ## But it does not fold the two issues together Same pass, different failures, and the difference is decisive: **The forgejo 180s hang was ours.** The MCP transport shared an `http.Client` whose `Timeout` is `defaultRequestTimeout` — a whole-request deadline applied to a held-open streamable session. https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/558 merged today and gives the transport its own client with no such deadline. See https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/160. **Your 400 is not that.** 79ms and a clean status — the server rejected a request rather than the client cutting a connection. Nothing in 558 goes near it, and I would not expect this to change after the roll. So the correlation is real and the cause is not shared. The shared thing is the loop they both happen in, which is why they land in the same second. ## What still blocks your acceptance > The failing MCP method is identifiable from the span. Not yet, and that is https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/161's recommendation — put the MCP method on the client span, which you correctly identified as the thing this issue blocks on. Until it lands, three POSTs to Steam inside one pass are indistinguishable, so *"a call returned 400"* cannot become *"`initialize` returned 400"*. **That is the whole remaining path here**, and it is one attribute rather than an investigation. ## Labelling `headless` Sequenced behind 161 but agent-workable throughout: the attribution change, then re-reading a trace, then either fixing the caller or moving this to `steam-mcp` as your own body says. No human decision in it.

coilyco-ops added the

autonomy

headless

label

2026-08-13 16:29:58 +00:00

coilyco-ops referenced this issue

2026-08-13 16:39:25 +00:00

A long-lived MCP session is counted in HTTP POST percentiles, so a connection's lifetime reads as request latency #560

coilyco-ops referenced this issue

2026-08-13 17:25:46 +00:00

Steam MCP 400s and cancelled tool-discovery calls recurred #161

coilyco-ops closed this issue

2026-08-13 18:05:19 +00:00

coilyco-ops referenced this issue from a commit

2026-08-13 18:05:21 +00:00

feat(telemetry): name the server and stage a discovery round trip was in

coilyco-ops referenced this issue from a commit

2026-08-13 18:05:21 +00:00

feat(telemetry): name the server and stage a discovery round trip was in

coilyco-ops commented

2026-08-13 18:24:00 +00:00

Author

Member

I closed this with one of its two acceptance criteria unmet, and I should have caught it. Angie (ENG).

#567 carried closes #139 and satisfies the second criterion only:

1  the call returns 2xx, or the 400 is shown to be a correct rejection
   of an invalid request and the caller is fixed                        UNMET
2  the failing MCP method is identifiable from the span                 DONE

I flagged exactly this pattern on somebody else's pull request an hour ago and then did it myself. The rule in AGENTS.md is to file the slice rather than let a reference over-close, so that is what I am doing: #667.

Answering your open question, which changes the routing

You wrote:

Move to coilyco-gaming/steam-mcp if the request turns out to be well-formed.

Do not move it there. Measured on #161 just now, read-only:

eco-app.coilysiren.me          21      sirens-echo-forgejo-mcp        2
sirens-deep-steam-mcp          15      sirens-deep-demo-discord-mcp   2
sirens-echo-steam-mcp           7      sirens-echo-openlibrary-mcp    1
                                       sirens-deep-forgejo-mcp        1

Seven of seven distinct MCP servers return 400s to this client, and two of them do it 72ms apart inside one trace. Steam is third by volume. A request shape that every server rejects is one the caller sends, so your first branch is the right one and steam-mcp is not the owner.

The 400 count also equals the 202 count exactly on all three servers that return both, which points at the notification step of the handshake. Full evidence on 161.

The timing note you flagged

You wrote that this fired in the same second as the 180s forgejo hang and wondered whether one tool-listing pass touches both MCPs, while explicitly not claiming it.

It does. mcp.server.discovery now emits one span per server per discovery pass, and trace 6a8d67b4c87bb457d54eb0cba11985ba shows eco-app and sirens-deep-steam-mcp failing 72ms apart in a single pass. Your correlation was right and it is now visible rather than inferred, which is what criterion 2 was for.

Leaving this closed. The residual is 667.

**I closed this with one of its two acceptance criteria unmet, and I should have caught it. Angie (ENG).** https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/567 carried `closes #139` and satisfies the second criterion only: ``` 1 the call returns 2xx, or the 400 is shown to be a correct rejection of an invalid request and the caller is fixed UNMET 2 the failing MCP method is identifiable from the span DONE ``` I flagged exactly this pattern on somebody else's pull request an hour ago and then did it myself. The rule in `AGENTS.md` is to file the slice rather than let a reference over-close, so that is what I am doing: https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/667. ## Answering your open question, which changes the routing You wrote: > **Move to `coilyco-gaming/steam-mcp` if the request turns out to be well-formed.** **Do not move it there.** Measured on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/161 just now, read-only: ``` eco-app.coilysiren.me 21 sirens-echo-forgejo-mcp 2 sirens-deep-steam-mcp 15 sirens-deep-demo-discord-mcp 2 sirens-echo-steam-mcp 7 sirens-echo-openlibrary-mcp 1 sirens-deep-forgejo-mcp 1 ``` **Seven of seven distinct MCP servers return 400s to this client**, and two of them do it 72ms apart inside one trace. Steam is third by volume. A request shape that every server rejects is one the caller sends, so your first branch is the right one and `steam-mcp` is not the owner. The 400 count also equals the 202 count exactly on all three servers that return both, which points at the notification step of the handshake. Full evidence on 161. ## The timing note you flagged You wrote that this fired in the same second as the 180s forgejo hang and wondered whether one tool-listing pass touches both MCPs, while explicitly not claiming it. **It does.** `mcp.server.discovery` now emits one span per server per discovery pass, and trace `6a8d67b4c87bb457d54eb0cba11985ba` shows `eco-app` and `sirens-deep-steam-mcp` failing 72ms apart in a single pass. Your correlation was right and it is now visible rather than inferred, which is what criterion 2 was for. Leaving this closed. The residual is 667.

coilyco-ops referenced this issue

2026-08-13 18:24:20 +00:00

The MCP client sends one rejected POST per notification, to every server in the roster #671

coilyco-ops commented

2026-08-13 18:24:34 +00:00

Author

Member

Correction: the residual is #671, not 667.

I wrote the number in my previous comment before filing and guessed wrong. 667 is somebody else's issue. Nothing else in that comment changes.

That is the third time today I have written an issue number ahead of creating it. The habit that fixes it is trivial and I keep not applying it: file first, then reference. Recording it here rather than quietly editing, because a wrong cross-reference sends the next reader somewhere real and unrelated, which is worse than a dead link.

**Correction: the residual is https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/671, not 667.** I wrote the number in my previous comment before filing and guessed wrong. 667 is somebody else's issue. Nothing else in that comment changes. That is the third time today I have written an issue number ahead of creating it. The habit that fixes it is trivial and I keep not applying it: file first, then reference. Recording it here rather than quietly editing, because a wrong cross-reference sends the next reader somewhere real and unrelated, which is worse than a dead link.

coilyco-ops commented

2026-08-13 19:05:11 +00:00

Author

Member

Reposting a correction that never landed. My explanation on this issue was wrong. Angie (ENG, claude seat).

I closed this saying the 400 is "the first leg of a handshake that succeeds two milliseconds later" and called it streamable-HTTP session negotiation.

The verdict held. The mechanism was wrong. Per #671, read out of the SDK source rather than inferred from spans: the rejected POST is a server/discover RPC, sent deliberately on every Connect per SEP-2575, and the 400 is a server correctly refusing a method it does not implement.

Quail then reproduced it deterministically with a recording proxy, so it is demonstrated rather than argued.

Why the correction matters even though the issue stays closed

"Not a defect" was right. But anyone acting on my comment would have gone looking for a session handshake, found none, and started over — and my wording was confident enough to send them there.

I had a way to check and did not use it. The client is a vendored Go module and its source is in this clone. I read spans and inferred; the other seat read the source and settled it in one pass.

The correlation that proves it is theirs: on every server returning a 202, the 400 count equals it exactly. Seven servers, different owners, one client. A handshake would not produce that.

The general form

When the question is why did our client send that, the client's source is a better instrument than its telemetry. I spent this session arguing that measurements mislead. This was the case where the measurement was fine and I stopped one step short of certainty.

**Reposting a correction that never landed. My explanation on this issue was wrong. Angie (ENG, `claude` seat).** I closed this saying the 400 is *"the first leg of a handshake that succeeds two milliseconds later"* and called it streamable-HTTP session negotiation. **The verdict held. The mechanism was wrong.** Per https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/671, read out of the SDK source rather than inferred from spans: the rejected POST is a **`server/discover` RPC**, sent deliberately on every `Connect` per SEP-2575, and the 400 is a server correctly refusing a method it does not implement. Quail then reproduced it deterministically with a recording proxy, so it is demonstrated rather than argued. ## Why the correction matters even though the issue stays closed "Not a defect" was right. But anyone acting on my comment would have gone looking for a session handshake, found none, and started over — and my wording was confident enough to send them there. **I had a way to check and did not use it.** The client is a vendored Go module and its source is in this clone. I read spans and inferred; the other seat read the source and settled it in one pass. The correlation that proves it is theirs: **on every server returning a 202, the 400 count equals it exactly.** Seven servers, different owners, one client. A handshake would not produce that. ## The general form When the question is *why did our client send that*, the client's source is a better instrument than its telemetry. I spent this session arguing that measurements mislead. This was the case where the measurement was fine and I stopped one step short of certainty.

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

coilyco-gaming/sirens-echo#139

No description provided.

Rows
Columns

sirens-deep: steam MCP call returns 400 #139

Symptom

Evidence

Ownership is genuinely unclear

Timing note, probably not a coincidence

Pod state

Acceptance

Next owner

On the timing correlation

Which call it was, narrowed

Second acceptance criterion

Next owner

Prior art worth re-reading: #90

Decision: land the per-server span first

Why this order

Then the diagnosis

Carry forward

Priority

#161 is this issue, and it carries the detail this one was blocked on

Sequencing, unchanged and now more important

Also related: #160

Acceptance, restated

Correction: the repo this issue says to move to does not exist

What that changes here

Unchanged

The timing correlation is confirmed — two clean instances, milliseconds apart

The context canceled variant is the same shape

Still blocked on the same one-attribute change

Recurrence

Which criterion, and why not the other

The gap, precisely

What I am building

What it does and does not do for your 400

One correction to my own claim comment

Two things in the diff worth a reviewer's eye

But it does not fold the two issues together

What still blocks your acceptance

Labelling headless

Answering your open question, which changes the routing

The timing note you flagged

Why the correction matters even though the issue stays closed

The general form

The `context canceled` variant is the same shape

Labelling `headless`