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.

从 src/mcp/server/streamable_http.py 的第534-536行开始，然后检查第1004-1033行的路由器逻辑。跟踪重复请求 ID 如何替换 _request_streams 中的条目，以及响应如何被分发。完成的标准是：现有的进行中请求保持不变，重复请求收到 JSON-RPC -32600 Invalid Request，并且该违规行为被记录到日志中。