Skip to content

Restore negotiated protocol version on reconnection transport#1591

Open
bhosmer-ant wants to merge 1 commit intomainfrom
fix/bug-130-reconnect-protocol-version
Open

Restore negotiated protocol version on reconnection transport#1591
bhosmer-ant wants to merge 1 commit intomainfrom
fix/bug-130-reconnect-protocol-version

Conversation

@bhosmer-ant
Copy link
Contributor

When Client.connect() is called with a transport that already has a sessionId set (i.e. reconnection), it skips the initialize handshake. Previously this meant transport.setProtocolVersion() was never called, so the new transport's _protocolVersion stayed undefined and all subsequent HTTP requests omitted the mcp-protocol-version header — violating the MCP spec's MUST requirement that clients include this header on all post-initialization requests.

This PR:

  • Stores the negotiated protocol version in Client._negotiatedProtocolVersion during the initial handshake
  • Restores it onto the new transport in the reconnection early-return path
  • Adds a getNegotiatedProtocolVersion() getter so users can retrieve it for manual transport construction
  • Adds a protocolVersion option to StreamableHTTPClientTransportOptions for users who create a fresh Client on reconnect (the pattern used in examples/client/src/simpleStreamableHttp.ts)

Resolves #812
Resolves #731

Motivation and Context

The bug is currently masked in SDK-to-SDK testing because the server's validateProtocolVersion() is intentionally lenient — it accepts missing headers and only rejects when the header is present with an unsupported value. But any stricter MCP server implementation that enforces the spec's MUST requirement would reject all post-reconnection requests.

How Has This Been Tested?

Two new tests:

  • test/integration/test/client/client.test.ts — verifies that reconnecting the same Client with a new transport (with sessionId set) restores the protocol version via setProtocolVersion()
  • packages/client/test/client/streamableHttp.test.ts — verifies the protocolVersion constructor option is honored and the header is included in outgoing requests

Existing reconnection tests (taskResumability.test.ts) continue to pass.

Breaking Changes

None. This is purely additive — a new private field, a new getter, and a new optional constructor parameter.

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

This is one of several bugs contributing to reconnection failures in the StreamableHTTP transport. Related issues that are partially addressed by this fix: #764, #852.

When Client.connect() is called with a transport that has a pre-set sessionId
(reconnection), it skips the initialize handshake. Previously this meant
transport.setProtocolVersion() was never called, so all subsequent HTTP
requests omitted the mcp-protocol-version header — violating the MCP spec's
MUST requirement.

This change:
- Stores the negotiated protocol version in Client during the initial handshake
- Restores it onto the new transport in the reconnection early-return path
- Adds a getNegotiatedProtocolVersion() getter for manual transport construction
- Adds a protocolVersion option to StreamableHTTPClientTransportOptions for
  users who create a fresh Client on reconnect

Addresses #812, #731
@bhosmer-ant bhosmer-ant requested a review from a team as a code owner February 26, 2026 03:58
@changeset-bot
Copy link

changeset-bot bot commented Feb 26, 2026

⚠️ No Changeset found

Latest commit: 1fb619c

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

@pkg-pr-new
Copy link

pkg-pr-new bot commented Feb 26, 2026

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1591

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1591

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1591

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1591

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1591

commit: 1fb619c

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant