Streamable HTTP client treats 404 as terminal instead of re-initializing, as the spec requires

Start in src/mcp/client/streamable_http.py at the 404 handling and inspect _send_session_terminated_error, then read src/mcp/shared/session.py to understand initialization state. Trace how the stored session id and InitializeRequest are managed. Done means a 404 for a session-bound request drops the session, re-initializes, retries once, and leaves a second 404 terminal.

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.