Skip to content

Fix uncaught exception in MCP server #822

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

Merged
merged 13 commits into from
Jun 10, 2025
Merged

Conversation

ddworken
Copy link
Contributor

Motivation and Context

This fixes an uncaught exception in the MCP server

How Has This Been Tested?

Via unit tests and locally.

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

@ddworken ddworken marked this pull request as ready for review May 27, 2025 20:58
@ddworken
Copy link
Contributor Author

@johnw188

@bruno-oliveira
Copy link

So to clarify, currently this is blocking from using the streamable-http transport inside clients such as Windsurf or Claude Desktop correct?

@ddworken
Copy link
Contributor Author

Hmm, this shouldn't be blocking any clients, it is just adding error handling for a previously unhandled exception. Have you observed issues with this PR in certain clients?

@Sillocan
Copy link

@bruno-oliveira This shouldn't be blocking anyone, but it does fix a huge security issue with remote servers. Currently anyone can lock up a server just by sending a bad payload #820

await self._handle_incoming(responder)
if not responder._completed: # type: ignore[reportPrivateUsage]
await self._handle_incoming(responder)
except Exception as e:

Choose a reason for hiding this comment

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

I think is better to handle a specific exceptions before the general one, such as RuntimeError (Which mentioned in this issue)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Given that the risk is the server becoming unresponsive, I believe catching all exceptions to isolate errors to a single request is correct.

Copy link
Member

Choose a reason for hiding this comment

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

I don't think this is a valid answer from the package's point of view.

It makes it considerably hard to maintain the package if everything is except Exception.

@Sillocan
Copy link

Sillocan commented Jun 8, 2025

I'm a bit baffled that a security issue like this is still open

Copy link
Member

@johnw188 johnw188 left a comment

Choose a reason for hiding this comment

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

LGTM

@johnw188 johnw188 merged commit 29c69e6 into modelcontextprotocol:main Jun 10, 2025
19 of 20 checks passed
Comment on lines +396 to +397
session_message = SessionMessage(
message=JSONRPCMessage(error_response))
Copy link
Member

Choose a reason for hiding this comment

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

How this got merged?

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.

6 participants