What the bug is. replay_then_relay (src/mcp/server/runner.py:676-681) is a pump task: it forwards buffered and live frames into the zero-buffer replay channel via await replay_send.send(...) with no exception containment. The consumer of that channel is the era dispatcher built by _serve_legacy_stream/_serve_modern_stream, and JSONRPCDispatcher.run() wraps its read loop in async with self._read_stream: (jsonrpc_dispatcher.py:487) — so on every exit path, including a handler exception propagating under raise_handler_exceptions=True, the dispatcher's unwind closes replayed (which ContextReceiveStream delegates to the underlying MemoryObjectReceiveStream). anyio wakes a sender parked in send() with BrokenResourceError when the receive end closes.

The code path. The relay runs in _replay_from_opening_request's task group, not the dispatcher's, so when the handler exception aborts the dispatcher's internal group and its unwind closes the replay channel, the relay task has not yet been cancelled — the outer tg.cancel_scope.cancel() only runs after the yield resumes, which happens after the child-task exception is already collected. The scheduling is decided against the code deterministically: run()'s outer finally hits a cancel-shielded checkpoint after closing the read stream and before the exception reaches the outer group, giving the woken relay task a chance to raise while its group is still live. The outer finally in _replay_from_opening_request only closes resources; it cannot suppress a child-task exception the group has already collected.

Step-by-step proof (empirically reproduced by a verifier — 17/20 runs):

1. Server runs serve_dual_era_loop(..., raise_exceptions=True) with a tools/list handler that raises RuntimeError.
2. The client pipelines three enveloped frames. The relay hands frame 1 to the dispatcher through the zero-buffer channel, then immediately pulls frame 2 and parks in replay_send.send().
3. Frame 1's handler raises; raise_handler_exceptions=True propagates it, crashing the dispatcher's task group.
4. The dispatcher's unwind exits async with self._read_stream:, closing replayed → the receive end of the replay channel.
5. anyio wakes the parked relay task with BrokenResourceError; it raises inside _replay_from_opening_request's task group before that group is cancelled.
6. The caller of serve_dual_era_loop receives ExceptionGroup([RuntimeError, BrokenResourceError]) instead of the RuntimeError alone.

Why nothing catches it today. Every other pump in the codebase contains exactly this shutdown-order race — stdio's stdin_reader/stdout_writer both catch anyio.ClosedResourceError (src/mcp/server/stdio.py:61,71), and the dispatcher's own read loop does too (jsonrpc_dispatcher.py:496) — but the relay pump added by this PR catches nothing. The existing debug-path test, test_dual_era_loop_raise_exceptions_reraises_unmapped_modern_handler_exceptions, sends exactly one frame, so the relay is parked in read_stream.receive() (cancelled cleanly) rather than in send() — the race is never exercised; with a pipelined second frame, its pytest.RaisesGroup(RuntimeError, ...) assertion would fail on the extra exception.

Impact. Confined to the raise_exceptions=True debug/in-process mode (production serving maps handler exceptions to wire errors and never crashes the dispatcher, so wire behavior is unchanged) — but on that path it pollutes the documented exception contract: callers expecting the handler's exception get an ExceptionGroup with a foreign BrokenResourceError mixed in. One verifier also probed the external-cancellation trigger and could not reproduce it (40/40 clean cancels), so the pipelined-frame-under-raise_exceptions path is the real, near-deterministic trigger.

How to fix. Match the stdio pump convention — wrap the relay body:

async def replay_then_relay() -> None:
    try:
        async with replay_send:
            for envelope in peeked:
                await replay_send.send(envelope)
            async for item in read_stream:
                await replay_send.send((_sender_context(read_stream), item))
    except (anyio.BrokenResourceError, anyio.ClosedResourceError):
        pass  # receiver gone: nothing left to relay to

What the bug is. This PR replaces the old on_notify on the dual-era stream path — which built the notification Connection at modern_version, the version captured from the request that locked the era — with a new _serve_modern_stream.on_notify (src/mcp/server/runner.py:789-792) that unconditionally uses LATEST_MODERN_VERSION. That runtime change is intentional and documented by the PR's own comment: "a notification runs at the latest served version; the modern protocol has nothing version-specific here" — with per-request envelopes there is no connection-level version for a notification to inherit, so no code change is warranted. The defect is in the test suite: test_dual_era_loop_modern_notification_dispatches_at_locked_version (tests/server/test_runner.py:1728) was not updated, even though this PR systematically renamed and re-docstringed every sibling era-lock test to the new decide-on-opening-request vocabulary (e.g. ..._never_locks → ..._leaves_the_connection_modern, ..._rejects_without_locking → ..._gets_the_supported_list).\n\nThe specific mismatch. The test's name says "dispatches at locked version" and its docstring reads: "Notifications carry no envelope, so on a modern-locked connection they dispatch with the locked protocol version." Both name and docstring describe the removed first-success-locks model. The shipped rule is different: notifications dispatch at the latest served modern version, regardless of which version the opening request declared.\n\nWhy the test still passes. MODERN_PROTOCOL_VERSIONS is currently the single-entry tuple ('2026-07-28',) (mcp_types/version.py), so "the opening request's version" and LATEST_MODERN_VERSION coincide. The assertion seen_versions == [LATEST_MODERN_VERSION] is satisfied under both the old and the new semantics, which is exactly why nothing caught the stale documentation.\n\nStep-by-step proof of the divergence. Suppose a second modern version 2027-XX-XX ships and LATEST_MODERN_VERSION moves to it: (1) A client opens a stdio connection with a request enveloped at 2026-07-28; opens_modern is true and _serve_modern_stream serves the connection. (2) The client sends a notification (no envelope, per spec). (3) on_notify builds Connection.from_envelope(LATEST_MODERN_VERSION, ...) = 2027-XX-XX — not the 2026-07-28 the connection was opened at. (4) The notification is version-gated (validate_client_notification) and its handler sees ctx.protocol_version at the newer version, silently diverging from the requests on the same connection. Whether that is the desired rule is a design question the code answers one way and the test's documentation answers the other way — the reader following the test name would predict step (3) yields 2026-07-28 and be wrong.\n\nImpact and why this is a nit. Nothing breaks at merge: the test passes and asserts the value the code actually produces. The cost is documentation accuracy — this is the only test pinning the notification-version rule, and it points future readers (and the author of the eventual second-modern-version PR) at semantics this PR deleted, in a file where every neighboring test was carefully rewritten to the new vocabulary.\n\nHow to fix. Rename the test to something like test_dual_era_loop_modern_notification_dispatches_at_the_latest_served_version and re-docstring it to the shipped rule ("notifications carry no envelope, so they dispatch at the latest served modern version"), matching the comment in on_notify. Alternatively, if per-connection versioning was actually intended, thread the opening request's route.protocol_version into on_notify — but the PR's own comment indicates the latest-served rule is deliberate, so the test rename is the right fix.

What the bug is. _sender_context (src/mcp/server/runner.py:652-654) reads the per-message sender snapshot off a context-aware stream with getattr(stream, "last_context", None) or contextvars.copy_context(). The or was clearly meant to cover the attribute-missing/None case, but contextvars.Context implements the Mapping protocol, so truthiness falls back to __len__ — an empty-but-valid Context is falsy. Verified empirically in this checkout: bool(contextvars.copy_context()) is False when no contextvars are set. When that happens, the or throws away the legitimately-captured sender snapshot and substitutes copy_context() evaluated in the peek loop / relay task — the server side's own context.\n\nWhy an empty snapshot is a real, reachable state. ContextSendStream.send() snapshots copy_context() unconditionally (src/mcp/shared/_context_streams.py:37), so a sender task with no contextvars set produces an empty snapshot as its genuine, intended context. That is not a degenerate case the machinery treats as "absent" — the dispatcher itself uses an explicit if sender_ctx is not None check before sender_ctx.run(...) (src/mcp/shared/jsonrpc_dispatcher.py:672-673), so an empty snapshot arriving through a ContextReceiveStream is honored there and the handler runs isolated under it, seeing every ContextVar's default. The new helper's or contradicts that deliberate None-check semantics, and its own docstring ("the per-message sender context a context-aware stream carries, else the current one").\n\nStep-by-step proof. (1) A context-aware transport's sender task — one that has set no contextvars — calls ContextSendStream.send(frame); the envelope captures an empty copy_context(). (2) The peek loop in _replay_from_opening_request receives the frame; ContextReceiveStream.receive() sets read_stream.last_context to the empty snapshot. (3) _sender_context(read_stream) evaluates empty_ctx or copy_context() → the empty context is falsy → the fallback runs, returning a snapshot of the relay/serve-loop task's context. (4) That substituted context rides the replay envelope; the dispatcher's _spawn runs the handler under it. (5) If the code that invoked serve_dual_era_loop had any contextvars set (auth principal, tracing state, app config), the handler now observes them — exactly the server-to-handler leak the ContextReceiveStream boundary exists to prevent. Pre-PR, the dispatcher read last_context directly off the transport stream and the handler correctly saw only defaults.\n\nWhy the PR's own test misses it. test_dual_era_loop_carries_the_sender_context_through_the_replay sets _SENDER_VAR before send(), so the captured snapshot is non-empty (truthy) and the or never fires. The empty-snapshot branch is exercised by every plain-stream path (where last_context doesn't exist at all — correct fallback) but never with a present-and-empty context.\n\nWhy this is a nit, not a blocker. The trigger is narrow: it needs a context-aware transport whose sender task carries zero contextvars and a serve-loop task that carries vars a handler reads. Over stdio the stdin-reader sender inherits the app context anyway, so an empty sender snapshot usually implies an equally empty serve-task context, making the substitution indistinguishable. No in-tree flow concretely misbehaves today. But the code silently violates the isolation boundary in a corner case, contradicts the dispatcher's established is not None contract, and the fix is one line.\n\nFix.\n\npython\ndef _sender_context(stream: ReadStream[Any]) -> contextvars.Context:\n ctx = getattr(stream, "last_context", None)\n return ctx if ctx is not None else contextvars.copy_context()\n\n\nOptionally add an empty-context case to the replay test (send without setting _SENDER_VAR, assert the handler sees the default rather than a var set in the serving task) to pin the boundary.

Finding 1 — the legacy refusal message asserts an event that may never have happened (src/mcp/server/runner.py:728-733).

_serve_legacy_stream refuses any enveloped request with:

connection was opened with the initialize handshake; 2026-07-28 envelope requests are not accepted on it

But under the new rule, _serve_legacy_stream is the fallback for every non-modern opening, not just a successful initialize:

• An envelope-less first request such as a pre-handshake ping — the PR's own test_dual_era_loop_an_envelopeless_first_request_opens_a_legacy_connection drives exactly this and asserts this INVALID_REQUEST refusal right after a ping opening, where no handshake ever ran.
• A bare server/discover (test_dual_era_loop_bare_discover_opens_legacy_and_keeps_the_handshake_available) — the opening request is refused METHOD_NOT_FOUND, so again no handshake happened at the point the message fires.
• opening is None — the channel closed or the _OPENING_PEEK_LIMIT flood cap fired before any request (test_dual_era_loop_stops_peeking_after_a_flood_of_pre_request_frames).

Step-by-step proof (ping case): (1) Client's first frame is ping with no _meta envelope. (2) _replay_from_opening_request yields it as opening; _has_modern_envelope returns False, so opens_modern is False and _serve_legacy_stream takes the connection. (3) The ping is answered {} under the init-gate exemption — initialize was never sent. (4) Client then sends tools/list with the full 2026 envelope. (5) on_request raises INVALID_REQUEST with a message claiming the connection "was opened with the initialize handshake" — factually false; the connection has never been handshaken. The pre-PR wording ("connection is locked to the legacy handshake era") was mode-descriptive and accurate in every opening; the PR's rewrite to event-descriptive wording introduced the inaccuracy, so this is not pre-existing. The error code and refusal behavior are exactly as designed; only the diagnostic is wrong — but it is delivered to precisely the era-confused client that most needs an accurate one.

Finding 2 — Server.run's docstring documents the removed model verbatim (src/mcp/server/lowlevel/server.py:704-708, untouched by the diff, still present after the review-fix commit c3b0e01):

Thin wrapper over serve_dual_era_loop: ... serving the legacy handshake era and the modern per-request-envelope era (the first era-distinctive message to succeed locks the connection).

That parenthetical is exactly what this PR deletes. Under the shipped code, serve_dual_era_loop computes opens_modern from the client's first request before any handler runs (runner.py:625-627), so success no longer matters: a failed 2026 opening probe (malformed envelope, unknown method, unsupported version) still fixes the connection modern, and a follow-up initialize gets -32022 — pinned by test_dual_era_loop_malformed_envelope_content_is_a_modern_era_error and test_dual_era_loop_failed_modern_request_leaves_the_connection_modern. Server.run is the public stdio entry point and the direct (and only in-tree) caller of serve_dual_era_loop, whose own docstring the PR rewrote to the new rule — so after merge the wrapper and the wrappee assert contradictory era rules on the public API surface, and a reader following Server.run's version would conclude a failed modern probe leaves the handshake available, the opposite of tested behavior. This is distinct from the earlier bot comment about _has_modern_envelope's docstring (different file, different docstring).

Why nothing catches either: docstrings and error-message strings aren't executable contracts; pyright, ruff, and the 100%-coverage suite are green with both in place (the test asserting the refusal message only checks the substring is present, not that it is accurate).

Impact and fix: no runtime effect in either case — routing, codes, and behavior are as designed. Two one-line string edits: (1) reword the refusal to the actual rule, e.g. "connection was opened as a 2025 handshake connection (first request carried no 2026-07-28 envelope); enveloped requests are not accepted on it"; (2) replace Server.run's parenthetical with the new rule, e.g. "(the client's first request decides the connection's era, once)".