-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Random error thrown on response #88
Comments
Got the same on Windows:
|
Hey team, I am encountering the same error. When the server-side response is delayed due to an extended process (>10 seconds), the error occurs. Although the server successfully returns the results, it crashes afterward, blocking the next requests. |
I've investigated the issue reported by @MarkusPfundstein in the mcp-obsidian project (MarkusPfundstein/mcp-obsidian#3). I was able to reproduce this issue with a minimal MCP server implementation that simply waits for a specified number of seconds: The behavior varies depending on the client: With MCP Inspector (10-second timeout):
With Claude Desktop app (1-minute timeout):
This issue seems to be specific to the Python implementation of MCP servers. For comparison, I also implemented the same functionality in TypeScript, which continues to operate normally even after timeout events. The crash occurs at the point where the server tries to send results back to the client after a long-running operation, making it particularly problematic for operations that involve external API calls or other time-consuming tasks. Steps to reproduce:
The key characteristic of this issue is that the server successfully returns results for long-running operations, but crashes afterwards, preventing it from accepting any subsequent requests. This makes it particularly problematic for scenarios involving external API calls or other time-consuming tasks, as the server becomes unusable after the first long operation. |
@7shi I am facing the same errors. Have you fixed them in some way? |
@lgesuellip I don't know how to fix it. I have not tried SSE. |
Thank you for the repro. That is very useful. That is helpful. I'll take a look. Can't promise any dates. |
Same here, I had been investigating this over a month. Thought my code and implementation was erroring.
|
I add a PR. With PR a server continues to respond in inspector after the timeouts. I have to yet test with Claude Desktop. |
I ended up patching the MCP SDK And working with a local copy as it was not sustainable. It was crashing all long requests. |
This commit adds support for request cancellation and tracking of in-flight requests in the MCP protocol implementation. The key architectural changes are: 1. Request Lifecycle Management: - Added _in_flight dictionary to BaseSession to track active requests - Requests are tracked from receipt until completion/cancellation - Added proper cleanup via on_complete callback 2. Cancellation Support: - Added CancelledNotification handling in _receive_loop - Implemented cancel() method in RequestResponder - Uses anyio.CancelScope for robust cancellation - Sends error response on cancellation 3. Request Context: - Added request_ctx ContextVar for request context - Ensures proper cleanup after request handling - Maintains request state throughout lifecycle 4. Error Handling: - Improved error propagation for cancelled requests - Added proper cleanup of cancelled requests - Maintains consistency of in-flight tracking This change enables clients to cancel long-running requests and servers to properly clean up resources when requests are cancelled. Github-Issue:#88
Describe the bug
Sometimes, I see a stacktrace printed in the logs of my mcp server. Claude eventually succeeds to response but I think its good to investigate it.
To Reproduce
Its hard to reproduce as it does not always happen. The code in my codebase that caused it to happen is this one:
Called in this context
The RunTime Error is NOT thrown
Expected behavior
No stacktrace?
Desktop (please complete the following information):
Additional context
Here is a full log
The text was updated successfully, but these errors were encountered: