Steam client refresh token does not establish a CM session in workload #13

New issue

Open

opened 2026-07-29 02:46:39 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-07-29 02:46:39 +00:00

Member

Observed after deploying source 906ff28a00. The base MCP is Ready and advertises all six tools. Both ExternalSecrets are Ready. A privacy-filtered get_account_licenses smoke call reaches steamio, connects to a Steam CM endpoint, then the websocket closes before the license milestone. kai-server can establish TCP to the same CM endpoint and the namespace has no NetworkPolicy, so basic egress is not the blocker. The tool returns a sanitized error after roughly 50 seconds and emits no account payload.

Relevant landed fixes already cover MCP v1 pinning, native async FastMCP execution, and tool-specific readiness. The remaining work must distinguish a rejected or incomplete refresh token from a steamio CM lifecycle failure. Bootstrap should not report success until the issued token proves it can establish a CM session. Failure cleanup must remain bounded.

Acceptance:

A fresh operator bootstrap produces a token that establishes a workload CM session.
get_account_licenses and get_pics_product_info succeed through a payload-filtered live smoke check.
Invalid or rejected tokens return a bounded sanitized error without hanging.
No token, account identifier, or license payload appears in logs, issues, or command output.

Observed after deploying source 906ff28a00e7359e01959094ff8b08e87288369f. The base MCP is Ready and advertises all six tools. Both ExternalSecrets are Ready. A privacy-filtered get_account_licenses smoke call reaches steamio, connects to a Steam CM endpoint, then the websocket closes before the license milestone. kai-server can establish TCP to the same CM endpoint and the namespace has no NetworkPolicy, so basic egress is not the blocker. The tool returns a sanitized error after roughly 50 seconds and emits no account payload. Relevant landed fixes already cover MCP v1 pinning, native async FastMCP execution, and tool-specific readiness. The remaining work must distinguish a rejected or incomplete refresh token from a steamio CM lifecycle failure. Bootstrap should not report success until the issued token proves it can establish a CM session. Failure cleanup must remain bounded. Acceptance: * A fresh operator bootstrap produces a token that establishes a workload CM session. * get_account_licenses and get_pics_product_info succeed through a payload-filtered live smoke check. * Invalid or rejected tokens return a bounded sanitized error without hanging. * No token, account identifier, or license payload appears in logs, issues, or command output.

coilyco-ops added the

autonomy

live-collab

priority

labels

2026-07-29 03:48:14 +00:00

coilyco-ops added

priority

and removed

priority

labels

2026-07-29 06:28:29 +00:00

coilyco-ops added

priority

and removed

priority

labels

2026-08-05 10:26:21 +00:00

coilyco-ops added the

role/engineer

label

2026-08-15 21:10:24 +00:00

coilyco-ops commented

2026-08-19 22:53:10 +00:00

Author

Member

Still failing, three weeks on, and one behaviour has regressed. Olaf (ops seat) hit this live at 2026-08-19 22:42 UTC during a status pass, before finding this issue. Folding the evidence here rather than leaving a duplicate open - #21 is closed as a duplicate of this.

Deployed pod steam-mcp-ff94577f-2mxkv, image ...3a0cacf2, up 2d1h, 0 restarts. Pod stderr at the moment of a get_account_licenses call:

22:42:46  Attempting to create a websocket connection to cmp1-iad1.steamserver.net:443 (load: 11.059566)
22:42:47  Websocket closed, cannot reconnect.
22:42:47  Websocket closed, cannot reconnect.

Same shape this issue describes: reaches a CM endpoint, websocket closes before the license milestone.

The regression. This issue records "The tool returns a sanitized error after roughly 50 seconds and emits no account payload." That is no longer true. I let the call run past 8 minutes with no result and no error, then stopped it myself. The bounded sanitized error is gone, so the third acceptance bullet - "Invalid or rejected tokens return a bounded sanitized error without hanging" - has moved from unmet to actively worse. Whatever produced the 50-second failure in July does not fire on the current image.

New evidence on scope. Aggregated over the pod's entire 2-day life, k8s.deployment.name = 'steam-mcp': body CONTAINS 'websocket' returns 3 rows total, all inside the hour of my call. The CM session connects lazily on first use and nothing had touched this plane since the pod started. That is worth knowing for the first acceptance bullet: there is no passive signal that the token is dead, so a fresh bootstrap needs an explicit post-bootstrap CM smoke check, not an absence of errors.

The other two planes are healthy, so this is isolated to the client/PICS surface: get_recently_played returned 6 records, and get_store_search_results("Eco") returned 10 items with appids and prices.

I did not read the token and did not attempt a bootstrap. The autonomy/live-collab label is right - the re-seed half needs an attended session per the deploy README's Steam Guard fallback.

**Still failing, three weeks on, and one behaviour has regressed.** Olaf (ops seat) hit this live at 2026-08-19 22:42 UTC during a status pass, before finding this issue. Folding the evidence here rather than leaving a duplicate open - #21 is closed as a duplicate of this. Deployed pod `steam-mcp-ff94577f-2mxkv`, image `...3a0cacf2`, up 2d1h, 0 restarts. Pod stderr at the moment of a `get_account_licenses` call: ``` 22:42:46 Attempting to create a websocket connection to cmp1-iad1.steamserver.net:443 (load: 11.059566) 22:42:47 Websocket closed, cannot reconnect. 22:42:47 Websocket closed, cannot reconnect. ``` Same shape this issue describes: reaches a CM endpoint, websocket closes before the license milestone. **The regression.** This issue records *"The tool returns a sanitized error after roughly 50 seconds and emits no account payload."* That is no longer true. I let the call run **past 8 minutes** with no result and no error, then stopped it myself. The bounded sanitized error is gone, so the third acceptance bullet - *"Invalid or rejected tokens return a bounded sanitized error without hanging"* - has moved from unmet to actively worse. Whatever produced the 50-second failure in July does not fire on the current image. **New evidence on scope.** Aggregated over the pod's entire 2-day life, `k8s.deployment.name = 'steam-mcp'`: `body CONTAINS 'websocket'` returns **3 rows total**, all inside the hour of my call. The CM session connects lazily on first use and nothing had touched this plane since the pod started. That is worth knowing for the first acceptance bullet: there is no passive signal that the token is dead, so a fresh bootstrap needs an explicit post-bootstrap CM smoke check, not an absence of errors. **The other two planes are healthy**, so this is isolated to the client/PICS surface: `get_recently_played` returned 6 records, and `get_store_search_results("Eco")` returned 10 items with appids and prices. I did not read the token and did not attempt a bootstrap. The `autonomy/live-collab` label is right - the re-seed half needs an attended session per the deploy README's Steam Guard fallback.

coilyco-ops referenced this issue

2026-08-19 22:53:17 +00:00

The Steam client/PICS plane cannot open its websocket, and get_account_licenses hangs unbounded instead of failing #21

coilyco-ops referenced this issue from coilyco-flight-deck/mcp-beaver

2026-08-19 23:03:24 +00:00

No auth scheme survives a session bootstrap, which is the single blocker on retiring both bluesky-mcp and steam-ops' authenticated half #91