MCP update_event returns mis-routed page_analytics response shape on parallel calls

[JohnTarbox]

Symptom

In a batch of 8 parallel update_event MCP calls, 3 returned page_analytics-shaped JSON instead of the expected update_event response (events: Jeezum Crow, Foodaroo, Holiday Show in Capital City).

The updates DID apply — verified by re-running each call and observing previousValues already contained the new field values. But the response went to the wrong tool's serializer.

Why this is concerning

This is a silent-success-with-wrong-response pattern. In a less paranoid run (e.g., automation that doesn't double-check by re-reading), a caller would see a "success-shaped" response, log it, and move on — missing that the response correlates to the wrong tool. If the wrong-shaped response had ever been treated as a failure response, retries would re-apply mutations.

Suspect

JSON-RPC request/response correlation in the MCP transport, or shared mutable state between tool handlers running concurrently in the Worker. Possible causes:

• A shared currentToolName / currentResponseSerializer module-level variable that gets clobbered when handlers run interleaved (Workers are single-threaded but await interleaves).
• An ID collision where two tool calls reuse the same JSON-RPC id and one response overwrites the other in the client mapping.
• A handler caching the last response shape per session and serving it cross-talk style.

Repro hint

Fire 8+ parallel MCP tool calls of mixed types (e.g., update_event + get_page_analytics in alternation). Watch for response shapes that don't match the id of the request.

mcp-server/src/tools/admin.ts:313 is update_event. mcp-server/src/tools/analytics.ts has get_page_analytics. Diff their handlers for any shared state.

Priority

Medium — silent and could mask real failures. Worth diagnosing before next round of bulk MCP work.

Notes

update_event writes did succeed (verified). Bug is purely in response routing/serialization, not in the mutation path.

Distinct from #120 (which is a venue-dedup race in suggest_event).

[JohnTarbox]

Update: confirmed upstream

This is MCP TypeScript SDK issue #1186 — "Zombie Task Collision in StreamableHTTPServerTransport" (open, P2, "ready for work").

Root cause (from upstream issue): the _requestToStreamMapping Map in StreamableHTTPServerTransport is keyed only by message.id and persists across the transport's lifetime. JSON-RPC clients can legitimately reuse low ids across distinct requests (e.g., reconnects, parallel in-flight calls), and the map silently overwrites on collision — handler results then route to the wrong client stream.

Confirmed by the mcp-claude bot at exact line: packages/server/src/server/streamableHttp.ts:755-758 — the disconnect callback cleans _streamMapping but leaves _requestToStreamMapping stale.

Repro: https://github.com/Miaoxingren/modelcontextprotocol-issue

Variant note: upstream's repro is sequential (Client A disconnects mid-flight → Client B reuses the same id). What we observed is the concurrent variant — 8 parallel in-flight calls in the same session, 3 cross-talked. Same _requestToStreamMapping defect, different trigger path. If a fix lands upstream that only addresses the sequential disconnect-reconnect path, our concurrent-call exposure remains. Worth verifying any fix covers both.

Why this propagates to us

• mcp-server/node_modules/@modelcontextprotocol/sdk/dist/esm/server/webStandardStreamableHttp.js:57-58 — same _requestToStreamMapping Map pattern in the SDK we depend on.
• mcp-server/node_modules/agents/dist/mcp/index.js:733-734, 1063, 1092, 1214 — agents package's StreamableHTTPServerTransport has its own copy of the same pattern. Persistent transport per Durable Object means the Map outlives any single request.
• Verified main branch of cloudflare/agents (packages/agents/src/mcp/worker-transport.ts:613, 658) still has the bug. Cloudflare's PR #936 (open, drops custom transport in favor of SDK transport) wouldn't fix it because the SDK transport has the same defect.

Scope (re-confirmed)

Path	Vulnerable?	Why
OAuth/DO path (Claude Cowork)	Yes	Persistent transport per session; Map is shared across concurrent in-flight requests
Legacy mmatf_ Bearer (direct curl)	No	handleLegacyMcpRequest() at mcp-server/src/index.ts:255, 274 creates fresh McpServer + transport per request

Mitigation until upstream fix lands

• Avoid parallel update_event (or any mixed-tool) batches via Claude Cowork. Serialize them.
• For admin batch operations, use direct curl with mmatf_ token (per reference_admin_mcp_token.md) — that path doesn't share state across requests.
• No code change needed on our side; this is a 3rd-party transport issue.