Streamable HTTP server silently drops in-flight request when client reuses a JSON-RPC id

Summary

When a client sends two JSON-RPC requests with the same id on the same Streamable HTTP session before the first response is delivered, StreamableHTTPServerTransport overwrites the per-id response stream slot without warning. The first request's caller hangs until its read times out, and the second response is delivered to whichever caller wins the race. The server logs nothing.

The MCP base protocol requires that "the request ID MUST NOT have been previously used by the requestor within the same session," so a duplicate id is a protocol violation by the client. But the server has no way to tell the client (or an operator) that the violation happened, which makes this very hard to diagnose downstream.

Where it happens

In src/mcp/server/streamable_http.py lines 534-536 at v1.27.1:

request_id = str(message.root.id)
self._request_streams[request_id] = anyio.create_memory_object_stream[EventMessage](0)
request_stream_reader = self._request_streams[request_id][1]

The assignment is unconditional. If request_id is already a key in _request_streams, the prior (send, receive) pair is dropped on the floor. The earlier request's writer eventually tries to push a response into a stream nobody is reading, and the earlier request's caller is reading a stream nobody will ever write to.

The router side at lines 1004-1033 uses the same str(id) keying to dispatch responses, so once the slot has been overwritten, response routing is undefined.

Reproduction signature

We hit this through an in-house client that was sending id: 1 for every concurrent tool call on a shared session. Under concurrent load, calls timed out and at least one caller received the wrong tool's response payload.

Proposed Behavior

When a request arrives with an id that already has an in-flight stream registered, the server should reject it with JSON-RPC -32600 Invalid Request and leave the existing in-flight request untouched. This:

1. Surfaces the spec violation to the client immediately instead of timing out.
2. Preserves the in-flight request that arrived first.
3. Gives operators a log line to diagnose against.

A weaker variant (log-only, no error response) would still be a meaningful improvement over silent data loss.

Bắt đầu tại src/mcp/server/streamable_http.py ở các dòng 534-536, sau đó kiểm tra logic router ở các dòng 1004-1033. Theo dõi cách các ID yêu cầu trùng lặp thay thế các mục trong _request_streams và cách các phản hồi được phân phối. Được xem là hoàn tất khi yêu cầu đang thực hiện hiện tại vẫn còn nguyên, yêu cầu trùng lặp nhận JSON-RPC -32600 Invalid Request và hành vi vi phạm được ghi log.