fix(server): settle pending JSON-mode responses when the streamable HTTP transport closes

[retif]

Fixes the close() half of #2559.

The SSE path is deliberately untouched. A POST-initiated SSE stream closing without a JSON-RPC response is specified by hosting:session:delete-cancels-inflight — the request handler has been aborted, so the request is cancelled, and a cancelled request gets no response. This PR only changes JSON response mode, where no such reading is available: the HTTP request simply never completes. (I originally wrote an error to in-flight SSE streams too; test-e2e failed on all three Node versions and was right to. That half is dropped, and #2691, where I first reported it, is corrected.)

Problem

In JSON response mode, handleRequest() returns a Promise<Response> that only send() resolves. A stream mapping's cleanup deletes the entry without settling that promise, so WebStandardStreamableHTTPServerTransport.close() while a POST is in flight leaves the HTTP request open until the socket dies.

This is #2559's second paragraph — "cleanup only deletes the entry without settling the promise, so close() during an in-flight JSON-mode POST leaves the HTTP request hanging" — reported there as pre-existing on both main and v1.x.

The caller cannot distinguish "never ran" from "ran, reply lost", so for a mutating call retrying may double-execute and giving up may drop a completed write. In practice it presents as a client hanging until its own idle timeout on a call the server has already stopped working on.

Change

• A new private settlePendingJsonResponses() runs in close() before the cleanup() loop, since cleanup() drops the mapping that holds resolveJson.
• It returns immediately unless enableJsonResponse is set and something is in flight.
• Outstanding ids are grouped by stream, because a batched POST shares one stream across several request ids; the response is resolved with a single object or an array, matching the shape send() already produces.
• Each outstanding id gets -32000 "Connection closed: the server transport closed before this request completed". An id that already has a real response (a batch sibling that completed first) reuses it rather than being overwritten.
• Resolution is guarded so one undeliverable response cannot stop the others being settled or prevent close() from completing.
• close() also clears _requestToStreamMapping, which it previously left populated.

NodeStreamableHTTPServerTransport wraps this transport, so it inherits the fix.

Scope

close() only, and only the JSON-response-mode path.

This does not address #2559's first half — JSON-mode mappings leaking one _streamMapping entry per completed POST — so that issue should stay open.

Tests

Three tests in packages/server/test/server/streamableHttp.test.ts under close() with a JSON-mode request in flight.

suite	result
packages/server	42 files, 478 tests, all passing
test/e2e	44 files, 2639 passing, 147 expected-fail — including hosting:session:delete-cancels-inflight, which this version leaves intact

Negative control, run against 3924de9's copy of the transport with the new tests kept: both behavioural tests hang to the 5 s test timeout, which is the defect itself. The third (is a no-op when nothing is in flight) passes either way by design.

tsgo -p packages/server/tsconfig.json --noEmit is clean. A changeset is included.

Not verified here

eslint/prettier were not run locally (tooling constraint on my machine). The added lines follow .prettierrc by hand — 4-space, single quotes, arrowParens: avoid, nothing over 140 columns — but CI is the authority.

The v1 line has the same defect and is not touched here. Happy to open the v1.x backport if you want it.

[changeset-bot]

🦋 Changeset detected

Latest commit: ba3b959

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 6 packages

Name	Type
@modelcontextprotocol/server	Patch
@modelcontextprotocol/core	Patch
@modelcontextprotocol/client	Patch
@modelcontextprotocol/server-legacy	Patch
@modelcontextprotocol/codemod	Patch
@modelcontextprotocol/core-internal	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/@modelcontextprotocol/client@2692

@modelcontextprotocol/codemod

npm i https://pkg.pr.new/@modelcontextprotocol/codemod@2692

@modelcontextprotocol/core

npm i https://pkg.pr.new/@modelcontextprotocol/core@2692

@modelcontextprotocol/server

npm i https://pkg.pr.new/@modelcontextprotocol/server@2692

@modelcontextprotocol/server-legacy

npm i https://pkg.pr.new/@modelcontextprotocol/server-legacy@2692

@modelcontextprotocol/express

npm i https://pkg.pr.new/@modelcontextprotocol/express@2692

@modelcontextprotocol/fastify

npm i https://pkg.pr.new/@modelcontextprotocol/fastify@2692

@modelcontextprotocol/hono

npm i https://pkg.pr.new/@modelcontextprotocol/hono@2692

@modelcontextprotocol/node

npm i https://pkg.pr.new/@modelcontextprotocol/node@2692

commit: ba3b959