Skip to content

fix: reject duplicate initialize requests in ServerSession#624

Draft
devcrocod wants to merge 1 commit intomainfrom
devcrocod/reject-duplicate-initialize
Draft

fix: reject duplicate initialize requests in ServerSession#624
devcrocod wants to merge 1 commit intomainfrom
devcrocod/reject-duplicate-initialize

Conversation

@devcrocod
Copy link
Contributor

ServerSession.handleInitialize() now rejects duplicate initialize requests with INVALID_REQUEST (-32600) error. clientCapabilities and clientVersion changed from var to AtomicRef-backed val, with atomic compareAndSet(null, ...) serving as both the guard and the write

How Has This Been Tested?

second initialize returns error, original capabilities preserved

Breaking Changes

none

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

Copilot AI review requested due to automatic review settings March 26, 2026 19:24
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR hardens the Kotlin server session initialization handshake by rejecting duplicate initialize requests and adds integration tests to validate the behavior (including concurrent initialization attempts).

Changes:

  • Reject duplicate initialize requests in ServerSession.handleInitialize() with JSON-RPC INVALID_REQUEST (-32600).
  • Make clientCapabilities and clientVersion read-only public properties backed by AtomicRef, using compareAndSet(null, ...) to atomically guard initialization.
  • Add JVM integration tests for first/duplicate/concurrent initialize behavior; adjust an existing client integration test to use a separate transport pair.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File Description
kotlin-sdk-server/src/commonMain/kotlin/io/modelcontextprotocol/kotlin/sdk/server/ServerSession.kt Adds atomic initialization guard and returns INVALID_REQUEST on duplicate initialize.
integration-test/src/jvmTest/kotlin/io/modelcontextprotocol/kotlin/sdk/server/ServerSessionInitializeTest.kt New tests covering first initialize success and duplicate/concurrent initialize rejection.
integration-test/src/commonTest/kotlin/io/modelcontextprotocol/kotlin/sdk/client/ClientTest.kt Fixes test setup by using a new transport pair for a second client/server connection.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +102 to +104
// Capabilities still reflect the first client, not overwritten
assertEquals("first-client", session.clientVersion?.name)
}
Copy link

Copilot AI Mar 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test claims to verify that capabilities from the first initialize are preserved, but both requests use the same default ClientCapabilities() and the assertion checks clientVersion instead. This can’t detect a regression where clientCapabilities gets overwritten—consider passing distinct capabilities per request and asserting session.clientCapabilities (or update the comment to match what’s being asserted).

Copilot uses AI. Check for mistakes.
@codecov-commenter
Copy link

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

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.

3 participants