Skip to content

fix(server): answer a close() during the priming write as Session not… - #2606

Draft
rxits wants to merge 3 commits into
modelcontextprotocol:mainfrom
rxits:fix/closed-transport-not-parse-error
Draft

fix(server): answer a close() during the priming write as Session not…#2606
rxits wants to merge 3 commits into
modelcontextprotocol:mainfrom
rxits:fix/closed-transport-not-parse-error

Conversation

@rxits

@rxits rxits commented Aug 2, 2026

Copy link
Copy Markdown

… found, not Parse error

handleRequest() re-checks _closed and answers 404 Session not found, but writePrimingEvent() awaits the user-supplied event store after those checks. A close() landing during that write left the priming event enqueueing onto an already-closed controller, and the resulting Invalid state error fell into the POST handler's catch-all, which answered 400 Parse error (-32700) — telling the client to fix a body that was never the problem.

writePrimingEvent() now returns early when the transport closed during the store write, the POST handler answers 404 Session not found at that suspension point like it does at the two before it, and the catch-all maps to 500 Internal error (-32603).

Genuine parse failures are unaffected: invalid JSON and invalid JSON-RPC messages are still answered 400 -32700 by the guards that precede it.

Motivation and Context

How Has This Been Tested?

Breaking Changes

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

… found, not Parse error

handleRequest() re-checks _closed and answers 404 Session not found, but
writePrimingEvent() awaits the user-supplied event store after those
checks. A close() landing during that write left the priming event
enqueueing onto an already-closed controller, and the resulting
Invalid state error fell into the POST handler's catch-all, which
answered 400 Parse error (-32700) — telling the client to fix a body
that was never the problem.

writePrimingEvent() now returns early when the transport closed during
the store write, the POST handler answers 404 Session not found at that
suspension point like it does at the two before it, and the catch-all
maps to 500 Internal error (-32603).

Genuine parse failures are unaffected: invalid JSON and invalid JSON-RPC
messages are still answered 400 -32700 by the guards that precede it.
@changeset-bot

changeset-bot Bot commented Aug 2, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: de1eec2

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

pkg-pr-new Bot commented Aug 2, 2026

Copy link
Copy Markdown

Open in StackBlitz

@modelcontextprotocol/client

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

@modelcontextprotocol/codemod

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

@modelcontextprotocol/core

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

@modelcontextprotocol/server

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

@modelcontextprotocol/server-legacy

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

@modelcontextprotocol/express

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

@modelcontextprotocol/fastify

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

@modelcontextprotocol/hono

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

@modelcontextprotocol/node

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

commit: de1eec2

rxits added 2 commits August 3, 2026 04:43
… callback

A user-supplied onsessioninitialized callback that throws is a
server-internal failure — the client's body parsed fine — so it now
answers 500 -32603 rather than 400 -32700. Update the middleware/node
expectation to match; the two parse-error assertions in the same file
cover genuinely invalid JSON and are unchanged.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant