Respond with the latest supported protocol version when initialize requests an unknown one - #1339
Open
psp65 wants to merge 3 commits into
Open
Respond with the latest supported protocol version when initialize requests an unknown one#1339psp65 wants to merge 3 commits into
psp65 wants to merge 3 commits into
Conversation
added 2 commits
August 27, 2026 23:06
Per JSON-RPC 2.0, a request carrying an id must receive a response; the server previously returned null for unknown methods, which surfaced as an HTTP 200 with an empty body through HTTP transports. Notifications (requests without an id) are still silently dropped. This also makes MCP 2026-07-28 clients' auto mode fall back to the legacy handshake via a clean, deterministic -32601 on the server/discover probe instead of relying on a synthesized parse error from the empty body. https://issues.amazon.com/issues/APPDEV-2256
… versions Per the MCP spec, a server that does not support the requested protocol version must respond with the latest version it supports. Previously handleInitialize left protocolVersion unset for unknown versions, so the Smithy model default (2024-11-05, the oldest version) leaked into InitializeResult. Add ProtocolVersion.latestVersion(), derived from the supported-version registry so it cannot drift as versions are added. The registry moves into an initialization-on-demand holder: computing the latest during class init of the sealed base class NPEs when a subclass INSTANCE is the first member of the hierarchy touched (base clinit reads a still-null INSTANCE; caught by McpServerIntegrationTest). Known versions are still echoed as-is; a missing protocolVersion param keeps its existing behavior. https://issues.amazon.com/issues/APPDEV-2257
adwsingh
approved these changes
Aug 29, 2026
adwsingh
marked this pull request as ready for review
August 29, 2026 00:14
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What behavior changes?
initializerequesting a protocol version the server does not know (e.g. a future revision) now answers with the latest version the server supports (2025-11-25today):{"result":{"protocolVersion":"2025-11-25", ...}}Previously
handleInitializeleft the field unset for unknown versions, so the Smithy model default —2024-11-05, the oldest version — leaked intoInitializeResult. Known requested versions are still echoed unchanged, and the behavior for a missingprotocolVersionparam is intentionally untouched (pinned by an existing test).Why is this change needed?
The MCP spec requires that a server that does not support the requested version respond with the latest version it does support. #1304's description documents this exact bug; it was fixed for
2025-11-25by adding that version to the known list, which left the general unknown-version fallback broken. This is the general fix, and step 2 of the 2026-07-28 ladder in #1337.How was this validated?
ProtocolVersionTest.latestVersionIs2025_11_25andMcpServerTest.initializeWithUnknownProtocolVersionAnswersLatestSupported(initialize @2026-07-28→"2025-11-25"); known-version echo was already covered by existing tests. Moduletest/checkgreen, including the integration suite.autoandlegacymodes) negotiate2025-11-25exactly as before.What should reviewers focus on?
ProtocolVersion.latestVersion()is derived from the supported-version registry so it cannot drift when future versions are added — and the registry moved into an initialization-on-demand holder. That holder is load-bearing: computing the max during class init of the sealed base class NPEs when a subclassINSTANCEis the first member of the hierarchy touched (base<clinit>runs while the subclass clinit is in progress and reads a still-nullINSTANCE). The integration suite caught this; the unit suite alone would not have.UnknownVersionbranch inhandleInitialize.Additional Links
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.