Skip to content

Handles message type Exception in lowlevel/server.py _handle_message function. Mentioned as TODO on line 528. #786

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

AishwaryaKalloli
Copy link
Contributor

Handles message type Exception in lowlevel/server.py _handle_message function.
Right now I am sending a error log if parameter raise_exception=False.
Initital commit, need feedback.

Motivation and Context

Addressing a TODO mentioned in the code, handling one of the unhandled types of message in server.

How Has This Been Tested?

Initial commit, testing pending, need feedback to move ahead.

Breaking Changes

Does not break existing flow. Since the method raises exception it will break the code in case of exception, however it is expected behaviour.

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

@AishwaryaKalloli
Copy link
Contributor Author

AishwaryaKalloli commented May 22, 2025

@Kludex I came across TODO mentioned in src/mcp/lowlevel/server.py by you while reading the code.

Would appreciate feedback on how to handle the exception. Since there is no request attached to the message I have sent a log notification response to the client with the error message.
Please let me know if it looks good.

@felixweinberger felixweinberger self-assigned this Jul 15, 2025
@felixweinberger felixweinberger self-requested a review July 15, 2025 12:14
felixweinberger added a commit to AishwaryaKalloli/python-sdk that referenced this pull request Jul 15, 2025
- Handle exceptions in match statement as suggested by TODO
- Use proper dict structure for error logging instead of ErrorData
- Add comprehensive tests with parameterization
- Include exception type, module, and args in log data

Reported-by: AishwaryaKalloli
Github-Issue: modelcontextprotocol#786
AishwaryaKalloli and others added 3 commits July 15, 2025 13:56
- Handle exceptions in match statement as suggested by TODO
- Use proper dict structure for error logging instead of ErrorData
- Add comprehensive tests with parameterization
- Include exception type, module, and args in log data

Reported-by: AishwaryaKalloli
Github-Issue: modelcontextprotocol#786
@felixweinberger
Copy link
Contributor

@AishwaryaKalloli thanks for your contribution!

Made some tweaks on top of your branch + rebased + added some test cases for exception handling. I don't think we should be using JSONRPC types for log messages, so changed this to a literal dict.gg

@felixweinberger felixweinberger requested review from Kludex and ihrpr and removed request for felixweinberger July 15, 2025 13:48
Comment on lines +619 to +622
"message": str(message),
"type": type(message).__name__,
"module": type(message).__module__,
"args": getattr(message, "args", None),
Copy link
Member

Choose a reason for hiding this comment

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

Can we instead pass the values that would be passed to __exit__?

exception_type, exception_value, exception_traceback


I'm assuming passing the data in this shape was your idea? Or do we do this somewhere else already?

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