Skip to content

Conversation

daamitt
Copy link
Contributor

@daamitt daamitt commented Oct 14, 2025

Set the Server session initialization state immediately after responding to InitializeRequest to fix the race condition that gives the following warnings

WARNING Failed to validate request: Received request before initialization was complete session.py:363 DEBUG Message that failed validation: method='tools/list' params={} jsonrpc='2.0' id=2 session.py:364 

Motivation and Context

For Stateful http mcp servers (when stateless_http=False) this change is required for most clients to work correctly. I have tested this with Claude desktop and VSC. Mcp Inspector does not show the issue as it does not automatically call tools/list after initialize.

This change brings the behaviour of the mcp python-sdk inline with the TS sdk
[TS SDK link] https://github.com/modelcontextprotocol/typescript-sdk/blob/caa25503cdfc449d116c204e866bccc2617d7037/src/server/streamableHttp.ts#L501

How Has This Been Tested?

A test case is attached to the PR
main.py

uv run pytest :
Results (19.93s):
633 passed
2 skipped
1 xfailed

Breaking Changes

No

Types of changes

  • [ x] 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

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

Additional context

@daamitt daamitt changed the title Set the Server session initialization state immediately after respond… fix: Set the Server session initialization state immediately after respond… Oct 14, 2025
@daamitt
Copy link
Contributor Author

daamitt commented Oct 14, 2025

Description mentions the warning msg but actually most MCP clients fail to list the prompts and tools due to this.

@maxisbey maxisbey added the bug Something isn't working label Oct 14, 2025
This test verifies that requests can be processed immediately after responding to InitializeRequest, without waiting for InitializedNotification. The test simulates the HTTP transport behavior where InitializedNotification may arrive in a separate POST request after other requests like tools/list.
Copy link
Contributor

@maxisbey maxisbey left a comment

Choose a reason for hiding this comment

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

Thank you for the PR! I ended up writing a unit test while investigating this PR just to validate the issue and my understanding. I've pushed that up to your branch since I already had it prepared.

@daamitt
Copy link
Contributor Author

daamitt commented Oct 15, 2025

Thank you for the test case, it captures the race condition well. The race condition is quite common when there are async awaits in the HTTP request handling - like custom middleware for auth.

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

Labels

bug Something isn't working

2 participants