The bug. The EOF arm of JSONRPCDispatcher.run() executes in this order (jsonrpc_dispatcher.py:557-561):

self._running = False
self._closed = True          # <-- flipped first
await self._on_read_eof()    # serve_stream's _drain runs here
self._revoke_in_flight()
self._fan_out_closed()

and notify() short-circuits unconditionally once _closed is set (jsonrpc_dispatcher.py:491-493, "dropped %s: dispatcher closed"). So the entire drain window — the new _EOF_DRAIN_WINDOW machinery whose whole purpose is to flush graceful-close traffic "while the output is still up" (_StreamConnection._drain's docstring) — runs with all notification writes disabled.

The code path that triggers it. At stdin EOF, _StreamConnection._drain (serving.py) calls server.close_subscriptions(), which closes each open ListenHandler stream's send side. Each handler's async for event in recv loop (subscriptions.py:226-229) then drains its remaining buffered events, delivering each via ctx.session.send_notification(event_to_notification(...), related_request_id=subscription_id). That routes through the request's dispatch context — whose target is still a live _Wire, since _revoke_in_flight() runs only after the drain hook — into _Wire.notify -> dispatcher.notify -> the _closed gate, where every event is silently discarded. The same gate also drops progress notifications from in-flight requests finishing inside the shielded 2s wait_for_in_flight() window.

Why the final result still lands (and why the tests miss it). The listen handler's SubscriptionsListenResult goes dctx.reply() -> _spend() -> _Wire.write -> _write_frame -> _write_stream.send, which never consults _closed, and the write stream stays open until the task-group join. So the result is delivered while every buffered event is not. The existing EOF test (test_stdin_eof_ends_open_listen_streams_gracefully...) publishes and delivers its one event before closing stdin, so it only ever observes ack + result — the exact frames that survive — and cannot catch this. One verifier also reproduced it empirically: driving a dispatcher with an on_read_eof hook mimicking serve_stream's drain, a handler that flushed a notification then returned its result left only the JSONRPCResponse on the wire; the notification was dropped.

Why this is wrong, not just suboptimal. The delivery premise is sound: at stdin EOF the peer closed only its write side and can still read stdout — that is the entire reason the shielded drain window exists. And this PR itself documents the intended behavior in docs/handlers/subscriptions.md: "when the client's input ends, the driver closes your open streams for you inside a short bounded window, in which each stream's final result is guaranteed to reach the departing peer and any events it still had buffered flush as time allows." In reality zero buffered events ever flush — not "as time allows" but never. ListenHandler.close()'s docstring ("drains its buffered events and sends its SubscriptionsListenResult") makes the same promise.

Step-by-step proof.

1. Client opens subscriptions/listen (id sub-1) over stdio; server acks.
2. Server publishes two ToolsListChanged events while the client's reader is briefly slow, so both sit buffered in the listen stream.
3. Client closes its write side (stdin EOF at the server) while still reading stdout.
4. run() exits the read loop, sets _closed = True (line 558), then awaits _on_read_eof() (line 559).
5. _drain calls close_subscriptions(); the handler's async for event in recv yields both buffered events and calls send_notification(..., related_request_id="sub-1") for each.
6. Both calls reach dispatcher.notify, hit if self._closed: at line 491, and are dropped with a debug log.
7. The handler returns; reply() writes the SubscriptionsListenResult through _write_frame, which lands. The departing peer receives the result but neither event — the documented "flush as time allows" delivered nothing.

Fix. A small reorder: flip _closed (or the part of it that gates notify()) after await self._on_read_eof() — e.g. run the drain first, or introduce a separate peer-gone flag set after the drain — keeping the post-drain _revoke_in_flight()/_fan_out_closed() sequence as-is. All three verifiers confirmed independently (one with an empirical wire-level reproduction); there were no refutations.

The bug

_StreamConnection.__init__ unconditionally installs on_read_eof=self._drain on its JSONRPCDispatcher (src/mcp/server/serving.py:168), and _drain (serving.py:239-244) calls self._server.close_subscriptions(). That hook was designed for the stdio wind-down ("the peer closed our input... close listen streams"), where one process = one connection and closing the server's streams only affects the departing peer.

But serve_legacy_stream (serving.py:295-318) builds the same _StreamConnection, and StreamableHTTPSessionManager.run_server now drives every stateful legacy HTTP session through serve_legacy_stream(self.app, ...) (streamable_http_manager.py:324) — where self.app is the one application-wide Server. Server.close_subscriptions() reaches the registered ListenHandler and calls ListenHandler.close(), which ends every stream in the handler's stream set — including the listen streams that handle_modern_request serves for 2026-07-28 clients through the same handler on the same Server, on completely unrelated HTTP connections.

Step-by-step proof

1. A mixed-era deployment: modern client M holds an open subscriptions/listen stream over streamable HTTP (served by handle_modern_request(self.app, ...) through self.app's ListenHandler); legacy client L has an ordinary stateful 2025-era session on the same server.
2. L closes cleanly. The SDK's own legacy client defaults terminate_on_close=True and sends DELETE (src/mcp/client/streamable_http.py:652,715).
3. The server's _handle_delete_request calls terminate() (streamable_http.py:777,785), which closes _read_stream_writer/_read_stream (lines ~805-807) while L's session serve task is parked in the dispatcher's read loop.
4. JSONRPCDispatcher.run() treats EndOfStream/ClosedResourceError as EOF and awaits self._on_read_eof() (jsonrpc_dispatcher.py:552-559) → _drain → self._server.close_subscriptions() → ListenHandler.close().
5. M's listen stream — on an unrelated connection — is gracefully ended: M receives its listen request's result and must re-listen and refetch, losing any events published between the close and the re-listen (there is no replay). Every other modern subscriber is churned the same way, on every legacy DELETE or session teardown.

Note the close is pure collateral: a legacy-era connection cannot itself own listen streams (subscriptions/listen is modern-only; the legacy era refuses enveloped requests and a bare one is METHOD_NOT_FOUND), so the terminating session gains nothing from the call.

Why this is a regression and why nothing else prevents it

On main, the manager drove legacy sessions through serve_loop, whose dispatcher had no EOF hook, and close_subscriptions() did not exist — legacy session teardown never touched listen streams. The PR's docs document the shared-ListenHandler caveat only for stdio ("It never bites on stdio... behind a listener it does") and serve_listener socket hosts; nothing covers this streamable-HTTP trigger, and no test pins it for HTTP (the shared-server test in test_serving.py covers two serve_stream connections, not the HTTP manager path). Each legacy session teardown additionally gains a shielded up-to-2s wait_for_in_flight drain (_EOF_DRAIN_WINDOW) that HTTP teardown never had.

The PR description's "still landing" note (moving listen-stream ownership per-connection and dropping the server-level close_subscriptions() verb) acknowledges the general shared-handler coupling, but that follow-up is not in this diff — as it stands, a routine legacy client disconnect in any mixed-era streamable-HTTP deployment churns all modern subscribers server-wide.

Fix

serve_legacy_stream should not close subscriptions on EOF: either pass a flag into _StreamConnection so its _drain skips close_subscriptions() for transport-internal legacy HTTP sessions (a legacy session can never own a listen stream, so nothing is lost), or scope the close to streams owned by the ending connection. The stdio/serve_stream behavior can stay as documented.

The bug

This PR restructures request cleanup: the old _handle_request had an inner finally that always popped the request's _in_flight entry (with an identity guard against evicting a reused id's newer entry). That finally is gone, and removal now lives solely in _JSONRPCDispatchContext._spend() (src/mcp/shared/jsonrpc_dispatcher.py:238-246), which is reachable only through reply() / reply_error().

The peer-cancel interrupt path never gets there. In _dispatch_notification (lines 679-686), a notifications/cancelled for an in-flight id does:

in_flight.dctx.cancel_requested.set()
if self._peer_cancel_mode == "interrupt":
    in_flight.dctx.close()   # swaps the write target for _VOID — does NOT touch _in_flight
    in_flight.scope.cancel() # interrupts the body

close() (lines 234-236) only does self._target = _VOID. The scope cancel then interrupts the body inside _handle_request (line 777), and because it is the scope's own cancellation, anyio absorbs it at the with scope: exit (cancelled_caught semantics). Execution falls straight through to the finally, which only calls _release_request_task() — a counter decrement. Neither reply() nor reply_error() runs (that silence is the PR's cancel design, and it is correct on the wire), so _spend() never runs, and self._in_flight[coerce_request_id(req.id)] is never deleted. _revoke_in_flight() at EOF (lines 817-820) also only calls close() on each entry without clearing the dict.

Step-by-step proof

1. Client sends request id 1 (subscriptions/listen, or any slow handler). _dispatch_request inserts _in_flight[1] = _InFlight(scope, dctx) and spawns _handle_request; the body parks (e.g. in anyio.sleep_forever() or waiting on the bus).
2. Client sends notifications/cancelled for id 1. _dispatch_notification finds the entry, calls dctx.close() (target → _VOID) and scope.cancel().
3. The body's await raises the cancelled exception; it propagates to the with scope: exit in _handle_request, where anyio absorbs it (scope.cancelled_caught = True). No exception escapes, so the except anyio.get_cancelled_exc_class() arm — which fires only for outer cancels that re-raise past the scope — does not run.
4. The finally decrements _request_tasks to 0. _in_flight still contains key 1, holding the CancelScope and the full _JSONRPCDispatchContext — including message_metadata, which for the legacy streamable-HTTP path is a ServerMessageMetadata carrying the entire Starlette Request.
5. Repeat: every open/cancel cycle adds one entry. A verifier ran this empirically against in-memory streams: after 5 cancels, _in_flight held 5 entries while _request_tasks was 0. The only escapes are the client reusing the same request id (blind overwrite) or connection teardown.

Why this matters and why nothing catches it

Repeated listen open/cancel cycles on a long-lived stdio connection are precisely the flow this PR ships (client.listen(...) cancels via notifications/cancelled over stdio now), so the leak accrues on the PR's own headline path — unbounded memory growth in the core dispatcher, on every seat and transport that uses peer_cancel_mode="interrupt" (the server default). The 18-case cancel-race suite asserts wire frames only; no test asserts table state after a cancel, so it merges green.

This is a regression, not a design necessity. The _InFlight docstring itself says the entry is "keyed until its answer commits", and a cancelled request never commits. Popping the entry in the interrupt branch (right next to dctx.close()), or after scope.cancelled_caught in _handle_request with the old identity guard, is safe: _spend() already guards with entry.dctx is self, so the deferred cancel-as-wakeup case (a handler that completes anyway and replies into the void) cleans up correctly either way.

All three verifiers confirmed independently, one with an empirical reproduction; there were no refutations.