Summary
The 2025-06-18 Streamable HTTP transport specification says that a client which receives
HTTP 404 in response to a request carrying an Mcp-Session-Id header MUST start a new
session by sending a new InitializeRequest without a session id.
StreamableHTTPTransport never does this. In src/mcp/client/streamable_http.py a 404 is
turned into a terminal error and the transport is left unusable:
if response.status_code == 404:
if isinstance(message.root, JSONRPCRequest):
await self._send_session_terminated_error(
ctx.read_stream_writer,
message.root.id,
)
return
_send_session_terminated_error emits JSONRPCError(code=32600, message="Session terminated")
and returns. There is no re-initialization path anywhere in the transport: the stored
session id is never dropped, no new InitializeRequest is sent, and the failed request is
never retried.
Why this matters
A server that restarts — an ordinary deploy — legitimately answers 404 for every session
id it no longer knows. Per the specification that is the correct server behaviour, and the
client is supposed to recover transparently. Because it does not, every connected client
is permanently broken by any server restart until a human reconnects it.
We hit this twice in one day on routine deploys of a hosted MCP server. From the server
side it is not fixable: adopting an unknown session id would mean fabricating a handshake,
because ServerSession starts in NotInitialized and the first request then raises
Received request before initialization was complete (src/mcp/shared/session.py), after
which the session manager tears the session down again.
Expected behaviour
On a 404 for a request that carried a session id: discard the stored session id,
re-initialize transparently, and retry the request once. A second 404 on the retry can
reasonably remain terminal.
Actual behaviour
The request fails with Session terminated and the transport stays dead for the rest of
the client's lifetime.
Version
mcp 1.28.1, Python 3.11.
Summary
The 2025-06-18 Streamable HTTP transport specification says that a client which receives
HTTP 404in response to a request carrying anMcp-Session-Idheader MUST start a newsession by sending a new
InitializeRequestwithout a session id.StreamableHTTPTransportnever does this. Insrc/mcp/client/streamable_http.pya 404 isturned into a terminal error and the transport is left unusable:
_send_session_terminated_erroremitsJSONRPCError(code=32600, message="Session terminated")and returns. There is no re-initialization path anywhere in the transport: the stored
session id is never dropped, no new
InitializeRequestis sent, and the failed request isnever retried.
Why this matters
A server that restarts — an ordinary deploy — legitimately answers 404 for every session
id it no longer knows. Per the specification that is the correct server behaviour, and the
client is supposed to recover transparently. Because it does not, every connected client
is permanently broken by any server restart until a human reconnects it.
We hit this twice in one day on routine deploys of a hosted MCP server. From the server
side it is not fixable: adopting an unknown session id would mean fabricating a handshake,
because
ServerSessionstarts inNotInitializedand the first request then raisesReceived request before initialization was complete(src/mcp/shared/session.py), afterwhich the session manager tears the session down again.
Expected behaviour
On a 404 for a request that carried a session id: discard the stored session id,
re-initialize transparently, and retry the request once. A second 404 on the retry can
reasonably remain terminal.
Actual behaviour
The request fails with
Session terminatedand the transport stays dead for the rest ofthe client's lifetime.
Version
mcp1.28.1, Python 3.11.