Work through the spec-conformance gaps recorded by the interaction suite

[maxisbey]

The tests/interaction/ suite is requirement-tagged against the MCP specification. Where
the SDK's behaviour fell short of the spec, the suite did not skip or xfail: it pinned the
actual behaviour and recorded the gap on the requirement entry. This PR is a burn-down of
those recorded gaps. It fixes fourteen of them in code (and deletes a fifteenth whose
behaviour had already been fixed but whose record had gone stale), narrows three more to
a precisely-stated residual, records two as deliberate, ecosystem-consistent choices, and
closes three long-standing upstream issues along the way. It spans the server's bearer-token
gate, the bundled OAuth authorization server, the OAuth client's use of discovered metadata,
the JSON-RPC error surface for cancellation / handler crashes / unhandled client callbacks,
the initialize handshake, an opt-in client-side capability pre-check, the explicit-token
progress API, and the elicitation requested-schema type. For every behaviour change, the
existing requirement-tagged test flips from pinning the gap to pinning the spec behaviour, so
the suite stays the source of truth for what conforms and what does not.

Commits

Commit / subject	What it closes, by behaviour
68e4eb28 Tighten requirements-catalog divergence notes to match current SDK behaviour	Bookkeeping only — no runtime change. Corrects four requirement entries whose recorded-gap notes had gone stale (one behaviour was already fixed; three were re-scoped or re-classified as intentional, cross-SDK-consistent choices).
bad42e28 Emit RFC 6750 scope= in WWW-Authenticate and validate token audience	The resource server's 401/403 challenges now advertise the required scopes via scope= (which the SDK client already reads to drive step-up); a request with no credentials gets a bare Bearer challenge instead of error="invalid_token" (RFC 6750 §3.1 says the error attribute SHOULD NOT appear when nothing was presented); and a token whose RFC 8707 audience names a different server is now rejected 401 invalid_token.
47639a2b Stop replying to cancelled requests; map unhandled handler exceptions to -32603	A request cancelled via notifications/cancelled now gets no response, per the spec's SHOULD (it was answered with code: 0). An unhandled exception in a request handler now produces JSON-RPC -32603 (INTERNAL_ERROR) with an opaque message instead of code: 0 carrying str(exc) — handler internals no longer leak to the peer; the exception is still logged server-side. raise MCPError(...) for a specific code is unchanged.
a1734460 Reject bearer tokens that carry no audience claim	Closes the hole the previous commit left: a verified token with no resource indicator at all was still accepted. When resource_server_url is configured the gate now fails closed (401 invalid_token). AuthSettings(verifier_validates_audience=True) opts out for verifiers that enforce aud themselves and cannot surface the claim; RefreshToken.resource is added so the audience binding survives a refresh. The SDK's own tutorials and example servers were teaching the bug and are fixed in the same commit.
884badc9 Use spec error codes for unhandled elicitation/create and roots/list	When a client has no elicitation_callback / list_roots_callback, the SDK still answers the server on its behalf. Those answers now use the codes the spec assigns — -32602 for elicitation/create (a client with no callback declared no modes, and a request for an undeclared mode MUST be answered -32602) and -32601 for roots/list — instead of -32600 for both. Messages unchanged; sampling stays at -32600 (the spec assigns no code there).
24061fe9 Reject non-HTTPS, non-loopback redirect URIs at client registration	The bundled authorization server's /register accepted any well-formed URL as a redirect_uris entry — cleartext http:// on a non-loopback host, javascript:, data:, fragment-carrying URIs. It now rejects anything that is not HTTPS or a loopback host (localhost, 127.0.0.1, [::1]) with 400 invalid_client_metadata, and rejects fragments (OAuth 2.1 §2.3). Separately, /token now answers an authorization-code exchange whose redirect_uri does not match the one used at /authorize with error=invalid_grant (RFC 6749 §5.2) instead of invalid_request. Closes #2629.
3eb352c8 Align OAuth client with spec on PKCE verification and scope selection	(a) The client now verifies PKCE support before starting an authorization-code grant, as the spec's Authorization Code Protection section requires: if AS metadata was discovered and its code_challenge_methods_supported is absent or omits S256, the flow raises OAuthFlowError instead of redirecting. (b) The client stops reading the authorization server's scopes_supported as a scope fallback — that list is a superset of any one resource's, so the SDK over-requested and triggered real access_denied failures. The spec's chain is WWW-Authenticate scope= → PRM scopes_supported → omit. Closes #1307.
1e2bd9be Reject a second initialize on an already-initialized session	A repeated initialize on a live connection was answered as a fresh handshake, silently overwriting the session's recorded client_params and negotiated protocol version — so a later check_capability answered against the second client's capabilities. It is now rejected -32600 ("Session already initialized") and the established session keeps serving. No compliant client is affected (ClientSession.initialize() is already idempotent). Legacy-only: 2026-07-28 removes initialize. Closes #2605.
8f60ebe5 Make the prompt test's opaque coverage workaround explicit	Test-only: a two-line comment explaining a deliberately non-obvious shape in one prompt test, so the next reader does not "fix" it into a coverage violation.
28f500c7 Add an opt-in strict_capabilities flag to Client and ClientSession	Additive, default-off. Client(..., strict_capabilities=True) rejects, before the request reaches the transport, a call to a method whose required server capability the connected server did not advertise — e.g. list_resources() against a server that only advertised tools, or subscribe_resource() when the server's resources capability does not set subscribe. The rejection is an MCPError with -32601 (METHOD_NOT_FOUND), the same code a compliant server returns for an unadvertised capability, so opting in changes where the rejection happens, not what callers catch. Mirrors the TypeScript SDK's enforceStrictCapabilities (also default-off); the same keyword-only parameter exists on ClientSession. Because the gate reads the negotiated server capabilities, combining it with a bare version pin (where the client never learns them) is refused at construction with a ValueError that names the fix. The method-to-capability table is exported as mcp_types.methods.SERVER_CAPABILITY_REQUIREMENTS, and the lifecycle capability-rule requirement entry is no longer marked untested.
eddfa29d Deprecate ServerSession.send_progress_notification	send_progress_notification takes an explicit progress token decoupled from any request's lifetime, so it can keep emitting progress for a request that has already completed — which the spec forbids ("Progress notifications MUST stop after completion"). It is deprecated in favour of the request-scoped Context.report_progress() / ServerSession.report_progress(), which reports against the inbound request's own token, no-ops when the caller did not ask for progress, and is closed with the request. The deprecated method keeps working and emits MCPDeprecationWarning. To make "stops when the request completes" hold on every dispatcher, the in-process direct dispatcher now closes its context with the request the way the JSON-RPC one already did.
3605ec09 Type the elicitation requested schema on the send side	ElicitRequestedSchema was a TypeAlias for dict[str, Any]; it is now a Pydantic model of the spec's restricted requested-schema subset, backed by a new PrimitiveSchemaDefinition union. ServerSession.elicit_form() (and the deprecated elicit() alias) and ClientPeer.elicit_form() accept only this model, so a nested-object property, an array-of-objects property, or an anyOf union is unconstructible at the only place a server author supplies a schema, rather than silently forwarded to the client — the spec restricts form-mode requested schemas to flat objects with primitive-typed properties ("complex nested structures, arrays of objects … are intentionally not supported"). The high-level Context.elicit() / elicit_with_validation() path is unchanged. Inbound is deliberately untouched: ElicitRequestFormParams.requested_schema stays a plain dict[str, Any] on the wire, so older servers that emit anyOf for Optional form fields still reach the client's elicitation callback.
c2b3e8ee Record two divergences as intentional, ecosystem-consistent choices	Bookkeeping only — no code or test behaviour change. Two interaction-suite divergence notes described their gaps as unenforced spec MUSTs without saying whether closing them was planned; both are deliberate and the notes now say so. (1) stdio_server does not redirect sys.stdout, so a handler print() corrupts the protocol stream — no MCP SDK redirects stdout, and a redirect would only catch print(), not os.write(1, ...) or C extensions writing to fd 1, so it would be a partial guard rather than a structural fix; the logging tutorial already tells stdio server authors to log to stderr. (2) No MCP SDK validates sender-side progress monotonicity; that MUST is a contract on the handler author, not on the transport, and the test pins the unvalidated pass-through.

Motivation

These are all places where the SDK was provably out of step with normative spec text (or an
RFC the spec defers to). Three of them are reported user-facing bugs (#2629, #1307, #2605);
the auth ones matter most — a resource server that accepts audience-unbound tokens, or a
built-in authorization server that registers javascript: redirect URIs, is the kind of
default a user has no way to notice. Working through them as one burn-down keeps the
requirement manifest honest: a gap that is fixed loses its record, a gap that is partially
closed gets a record stating exactly the residual, and a gap that is a deliberate choice
says so — so what remains recorded is real and current.

Tested

./scripts/test (the full suite under the 100% line+branch coverage gate plus
strict-no-cover) is green at HEAD: 4303 passed, 7 skipped, 1 xfailed (the one
xfail is pre-existing and unrelated — a Pydantic AnyUrl trailing-slash quirk in
tests/client/test_auth.py), coverage 100.00%. pyright reports 0 errors;
ruff check / ruff format are clean; the new-suppression audit
(git diff ... | grep -E '^\+.*(pragma|type: ignore|noqa)') is empty. Every behaviour
change flips an existing requirement-tagged interaction test rather than only adding a new
one, so the old behaviour cannot silently come back. New tests cover the fail-closed
audience gate (including the verifier_validates_audience opt-out and the refresh chain),
the loopback/fragment matrix at /register, the PKCE-refusal arms (absent field, list
without S256, no-metadata leniency), the double-initialize rejection on stdio, stateful
HTTP, and stateless HTTP, the strict_capabilities pre-wire rejection alongside the
default send-and-surface behaviour, the request-scoped progress close on both dispatchers,
and the typed ElicitRequestedSchema construction/rejection matrix and its to_wire()
round-trip.

Breaking changes

All documented in docs/migration.md (one section each):

• Bearer tokens are rejected unless their audience names this server — including tokens
  that carry no resource indicator at all. Populate AccessToken.resource in your
  TokenVerifier (recommended; the examples now show it), or set
  AuthSettings(verifier_validates_audience=True) if your verifier already enforces aud
  and cannot surface it. resource_server_url=None still disables the check.
• Bundled authorization server: RFC-correct redirect-URI handling — /register rejects
  non-HTTPS, non-loopback, and fragment-carrying redirect URIs with invalid_client_metadata
  (this also rejects RFC 8252 private-use schemes such as com.example.app:/callback; MCP
  allows only HTTPS or loopback); /token answers a redirect-URI mismatch with
  invalid_grant instead of invalid_request.
• OAuth client refuses to authorize when AS metadata does not advertise S256 PKCE —
  OAuthFlowError instead of proceeding. No SDK-side opt-out: an authorization server that
  supports S256 but omits the field needs its published metadata fixed (RFC 8414 §2).
• OAuth client no longer reads scopes_supported from authorization-server metadata to
  choose a scope — if that was your only scope source, the client now omits scope
  entirely; pass an explicit scope on OAuthClientMetadata to keep the old request.
• Unhandled handler exceptions return -32603; cancelled requests get no reply — code
  that matched on the previous code: 0 responses must update; raise MCPError for a
  specific code, and note the exception text is now logged, not sent.
• Unhandled elicitation/create returns -32602; unhandled roots/list returns
  -32601 — server code that branched on error.code == -32600 to detect a client
  without these should switch codes, or (better) check the client's declared capabilities
  before sending.
• A second initialize on an already-initialized session is rejected with -32600
  ("Session already initialized"). A peer that needs a fresh handshake opens a new
  connection (on streamable HTTP, a POST without Mcp-Session-Id).
• ServerSession.elicit_form() (and the deprecated elicit() alias) and
  ClientPeer.elicit_form() now take a typed mcp_types.ElicitRequestedSchema, not an
  arbitrary dict[str, Any] — ElicitRequestedSchema is the model now, no longer a
  TypeAlias for dict[str, Any]. Build it directly
  (ElicitRequestedSchema(properties={"x": StringSchema(type="string")}, required=["x"]))
  or validate an existing JSON Schema dict with ElicitRequestedSchema.model_validate(...).
  Schemas with nested-object properties, array-of-objects properties, or anyOf unions are
  rejected at construction instead of being forwarded. The high-level Context.elicit() /
  elicit_with_validation() path and the inbound/wire representation are unchanged.
• ServerSession.send_progress_notification() is deprecated in favour of the
  request-scoped Context.report_progress() / ServerSession.report_progress(). The
  method still works, but every call now emits mcp.MCPDeprecationWarning — so test suites
  that run with filterwarnings = ["error"] (or -W error) will start failing on it.
  report_progress uses the inbound request's own token and cannot emit progress after that
  request has completed, which is what the spec requires.

Not a breaking change, but called out for completeness: Client(..., strict_capabilities=)
(and the same keyword on ClientSession) is additive and opt-in. The default is False
and the default behaviour is byte-for-byte unchanged — every request is still sent and the
server's answer is still surfaced.

Closes

Closes #2629
Closes #1307
Closes #2605

_{AI Disclaimer}

[cubic-dev-ai]

2 issues found across 29 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/mcp/shared/auth_utils.py">

<violation number="1" location="src/mcp/shared/auth_utils.py:32">
P2: Audience canonicalization can throw `ValueError` on malformed resource ports, breaking auth flow with a server error.</violation>

<violation number="2" location="src/mcp/shared/auth_utils.py:83">
P2: Audience validation is over-permissive because trailing slashes are stripped before comparison, so different resource URIs like `/api` and `/api/` are treated as equivalent.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

P2: Audience validation is over-permissive because trailing slashes are stripped before comparison, so different resource URIs like /api and /api/ are treated as equivalent.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/mcp/shared/auth_utils.py, line 83:

<comment>Audience validation is over-permissive because trailing slashes are stripped before comparison, so different resource URIs like `/api` and `/api/` are treated as equivalent.</comment>

<file context>
@@ -65,6 +72,19 @@ def check_resource_allowed(requested_resource: str, configured_resource: str) ->
+    origin is NOT for this server. Contrast check_resource_allowed, which is the
+    client-side hierarchical question and intentionally more permissive.
+    """
+    return resource_url_from_server_url(token_resource).rstrip("/") == resource_url_from_server_url(
+        server_resource
+    ).rstrip("/")
</file context>

[maxisbey]

You are right at the RFC 3986 layer — strict equivalence distinguishes /api/ from /api. But RFC 8707 defines no comparison algorithm, and its own examples use trailing-slash resource URIs. Two things make the normalization load-bearing: pydantic's AnyHttpUrl renders a root resource as https://h/ while the spec's example token request sends the slashless form — strict comparison would 401 every conformant client of a root-path deployment. And the compared value is the verifier-asserted audience from the validated token, not raw client input; exploiting the leniency would need two distinct resource servers at one origin differing only by a trailing slash, which a Starlette mount cannot host. Keeping the rstrip; c53aefd adds a comment plus tests pinning the equivalence and the sibling/child-path rejections.

_{AI Disclaimer}

[cubic-dev-ai]

The parent comment was wrong here: this audience comparison is intentionally load-bearing for RFC 8707 resource validation. The root-path and verifier-asserted-audience cases make the trailing-slash normalization necessary, so keeping the rstrip('/') is correct.

[cubic-dev-ai]

1 issue found across 36 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/mcp/shared/auth_utils.py">

<violation number="1" location="src/mcp/shared/auth_utils.py:83">
P2: Audience validation is over-permissive because trailing slashes are stripped before comparison, so different resource URIs like `/api` and `/api/` are treated as equivalent.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 46 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/mcp/shared/direct_dispatcher.py">

<violation number="1" location="src/mcp/shared/direct_dispatcher.py:111">
P3: This overstates the DirectDispatcher contract: notification handlers are not flattened to plain MCPError. Narrow the doc to request dispatch paths, or update notification handling separately.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

P3: This overstates the DirectDispatcher contract: notification handlers are not flattened to plain MCPError. Narrow the doc to request dispatch paths, or update notification handling separately.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/mcp/shared/direct_dispatcher.py, line 111:

<comment>This overstates the DirectDispatcher contract: notification handlers are not flattened to plain MCPError. Narrow the doc to request dispatch paths, or update notification handling separately.</comment>

<file context>
@@ -107,6 +107,11 @@ class DirectDispatcher:
     handler. Notifications are fire-and-forget in both directions: after close
     they are silently dropped.
+
+    Handler-raised `MCPError` subclasses flatten to plain `MCPError` with equal
+    `ErrorData` on every dispatch path, matching the wire, where subclass
+    identity cannot survive; callers needing the subclass rehydrate it from
</file context>

[claude]

🔴 The client now silently swallows any 204 on a request POST (src/mcp/client/streamable_http.py:268-274) on the assumption the waiter was already retired at cancel time, but the server's JSON-response mode also sends 204 when the per-request stream closes for non-cancel reasons (session teardown mid-request, idle-timeout eviction, operator DELETE), and a non-SDK server may answer a request POST with 204 outright — in those cases the client's waiter is still pending and nothing is ever delivered, so with the default read_timeout_seconds=None the caller hangs forever where it previously got a fail-fast error. Consider only swallowing the 204 when the request id is no longer pending, and otherwise retiring the waiter with a synthesized error (a synthesized error for an already-retired cancel waiter is dropped harmlessly).

Extended reasoning...

The bug. _handle_post_request in src/mcp/client/streamable_http.py (lines 268–274) now treats 202 and 204 identically: it logs and returns, with the comment that for a 204 "the waiter was retired at cancel time." That justification only holds when this client initiated the cancellation (its send_raw_request finally retires the pending waiter before the courtesy notifications/cancelled goes out). A 204 has other producers for which the waiter is very much still pending, and for those the silent return means nothing — no response, no error — is ever delivered to the dispatcher for that request id.

The non-cancel 204 producers. On the SDK server side, the JSON-response-mode wait loop in src/mcp/server/streamable_http.py (~lines 564–587) sends 204 whenever the per-request stream closes without a JSONRPCResponse/JSONRPCError frame — and its own comment names two causes: "peer-cancelled … or the session tore down mid-request." terminate() (and connect()'s cleanup) closes the send side of every in-flight per-request stream without routing any reply, so a server-initiated session termination — StreamableHTTPSessionManager's session_idle_timeout evicting a session whose handler outlives the idle deadline, an operator/external DELETE on the session id, or session-manager shutdown — while a client request is in flight produces exactly this 204. Separately, a non-SDK server may (non-compliantly) answer a request POST with 204 directly. In none of these cases did the client cancel anything.

Why nothing else saves the caller. The dispatcher only fails pending waiters when the ClientSession itself closes; the client's read stream stays open after the swallowed 204, and session death is only discovered by later requests. Client and ClientSession both default read_timeout_seconds=None, so the original caller's send_request blocks indefinitely.

Pre-PR vs post-PR (the regression). Before this PR, the same server condition produced a 500 ("No response message received before stream closed"), which the client's ≥400 path mapped to an INTERNAL_ERROR JSONRPCError delivered to the waiter — fail fast. A non-SDK 204 to a request POST hit the unexpected-content-type/parse path and likewise failed the waiter. Both paths now regress from "caller gets an error" to "caller hangs forever." The new test coverage only exercises the cancel flow (where the waiter is already retired), so the regression is not pinned by the suite.

Step-by-step proof. (1) Server runs streamable HTTP with json_response=True and an idle timeout; client issues tools/call (id 1) whose handler runs longer than the idle deadline. (2) The session manager's idle deadline fires (it is only pushed forward by inbound requests), cancels the serve loop, and calls terminate(), which closes every per-request stream; the parked JSON wait loop exits with response_message=None and the POST completes 204. (3) The client's _handle_post_request sees 204, logs "Received 204", and returns — the waiter for id 1 was never retired because the client never cancelled. (4) Nothing else ever resolves that waiter; with the default read_timeout_seconds=None the caller's await client.call_tool(...) blocks forever. Pre-PR, step (2) yielded a 500 and step (3) delivered an INTERNAL_ERROR to the waiter immediately.

Mitigating factors. json_response=True is non-default; the default SSE mode already had an analogous silent-hang shape pre-PR (stream ends with no event id → task returns); and the mainline cancel flow handled by this PR is correct and requirement-pinned (client-transport:http:204-settled-exchange). So this is a narrow trigger — but it is a hang-vs-error regression introduced by this PR, and an indefinite hang is strictly worse than the prior error surface.

How to fix. Only swallow the 204 when the request id is no longer pending in the dispatcher (i.e. this client cancelled it), and otherwise retire the waiter by writing a synthesized JSONRPCError for message.id to read_stream_writer (e.g. INTERNAL_ERROR, "Request settled by server with no response"). In the legitimate cancel case the synthesized error is harmless — the waiter is already retired and late responses for unknown ids are dropped — so unconditionally synthesizing on 204 for request POSTs would also restore fail-fast without breaking the cancel flow.

[claude]

🔴 With resumability (an event_store) enabled, a cancelled or timed-out request re-creates the hang/leak the new RequestSettled marker was added to fix: the priming event gives the client a last_event_id, so when the settled POST stream ends with no response it reconnects with Last-Event-ID, and _replay_events (having nothing to replay and nothing recorded for the settled id) re-registers a fresh _request_streams entry and parks forever — leaving one permanently open GET, a dead per-request stream on the server, a parked client transport task, and an extra priming row in the event store per cancellation. Pre-PR the stored code-0 'Request cancelled' error terminated both sides even with resumability, so this is a regression on that arm; a fix is to record a terminator (or drop the stream) in the event store for a settled id, have _replay_events end the GET instead of re-registering an id with no live request, and/or have the client skip reconnection when the only event seen was the priming event for an already-retired waiter.

Extended reasoning...

The bug. The new RequestSettled marker (emitted by the dispatcher when a peer cancellation interrupts a handler) is consumed in message_router (src/mcp/server/streamable_http.py:978-989): it closes the per-POST stream's send side and deliberately stores nothing in the event store ('Nothing is stored or sent on the wire'). That cleanly ends the exchange when no event store is configured — which is exactly the case the client's new no-reconnect early-out covers (src/mcp/client/streamable_http.py:383-388, whose own comment says 'No priming event (no event store) means no id'). With an event store configured, the same cancellation re-creates the hang the marker was added to fix, plus a per-cancellation server-side leak.

The code path. (1) A 2025-11-25+ client POSTs tools/call (id=N) to a server constructed with an event_store. _handle_post_request mints a priming event with an SSE id (_mint_priming_event, src/mcp/server/streamable_http.py:285-301) and _run_sse_writer sends it first; the client records it as last_event_id (_handle_sse_response, src/mcp/client/streamable_http.py:362-363; _handle_sse_event treats the empty-data priming event as non-complete). (2) The caller times out or scope-cancels; the dispatcher sends the courtesy notifications/cancelled, the handler is interrupted, and the dispatcher emits RequestSettled. message_router closes _request_streams[N][0], the SSE writer ends, its finally removes the _request_streams entry, and the POST exchange closes — no response frame, nothing written to the event store. (3) On the client, _handle_sse_response sees the stream end without a response, but last_event_id is not None, so the early-out does not apply: it calls _handle_reconnection, which re-GETs /mcp with Last-Event-ID. (4) On the server, _handle_get_request routes the header to _replay_events (src/mcp/server/streamable_http.py:854-917): replay_events_after finds nothing after the priming id, returns the stream id, which is no longer in _request_streams, so replay_sender re-registers it, mints and stores another priming event row, and parks forever in async for event_message in msg_reader — the dispatcher already settled that id, will never write a response for it, and message_router only closes per-request streams on a RequestSettled, which will not recur for that id. (5) The client's transport task likewise parks in the reconnected GET; if that connection ever drops on a normal stream end, _handle_reconnection recurses with attempt=0, so MAX_RECONNECTION_ATTEMPTS does not bound it and it polls indefinitely.

Why nothing prevents it. The client-side early-out is explicitly scoped to the no-event-store case; the RequestSettled marker is intentionally never persisted, so a resuming client has no way to learn the request settled; and _replay_events interprets 'stream id not in _request_streams' as 'resume a live stream' rather than 'this request is gone'. The PR's new cancellation tests (hosting:http:cancel-ends-post-sse-stream, cancel-json-mode-204, and the client-side 204 test) all run without an event store, so the resumability arm is untested.

Step-by-step proof. Server: StreamableHTTPSessionManager(..., event_store=InMemoryEventStore()), one tool that blocks on an anyio.Event. Client: streamable_http_client + Client, call the blocking tool inside a cancel scope and cancel it after the handler starts (the same shape as the PR's new cancel tests, just with an event store). Sequence: priming event id=E1 arrives → client sets last_event_id=E1 → cancel → courtesy notifications/cancelled → dispatcher emits RequestSettled(N) → message_router closes the per-POST stream, exchange ends → client sees no response but last_event_id=E1, so it GETs with Last-Event-ID: E1 → replay_events_after(E1) replays nothing, returns stream id N → not in _request_streams → re-register, store priming event E2, park in msg_reader forever. Inspecting the transport afterwards shows a re-registered _request_streams[N] entry and an open GET that never closes; the client task never returns. Repeat per cancellation/timeout — connections, tasks and event-store rows accumulate until whole-session teardown. Before this PR, step 'dispatcher emits RequestSettled' was instead 'dispatcher writes JSONRPCError(code=0, "Request cancelled")', which message_router stored in the event store and routed to the stream, terminating both sides cleanly even with resumability.

Impact. Per cancelled or timed-out request on a resumability-enabled server: one permanently open GET SSE connection, a re-registered dead _request_streams entry server-side (released only at session teardown), one permanently parked client transport task, and an extra priming-event row written to the event store on each reconnect. Ordinary client request timeouts trigger the courtesy cancel, so this is hit by routine timeout handling, not just explicit user cancellation, whenever the documented resumability feature is on.

How to fix. Any of: have message_router (or the dispatcher path) also drop/terminate the event-store stream for a settled request id so a resume has something definitive to replay; have _replay_events end the GET (instead of re-registering and parking) when the replayed stream id has no live request stream and no pending request; and/or have the client not reconnect when the only event ever received was the priming event for a request whose waiter has already been retired. Adding a resumability-enabled variant of the new cancellation interaction tests would lock the behaviour in.