Handles message type Exception in lowlevel/server.py _handle_message function. Mentioned as TODO on line 528. #786
+91
−2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@Kludex I came across TODO mentioned in 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. |
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
felixweinberger
added a commit
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: #786
|
@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. |
felixweinberger
requested review from
Kludex and
ihrpr
and removed request for
felixweinberger
Kludex
reviewed
Jul 15, 2025
gspencergoog
pushed a commit
to gspencergoog/mcp-python-sdk
that referenced
this pull request
Jul 29, 2025
…-h5-and-h6-styles-globally Apply `h5` and `h6` styles to all content
Initital commit, need feedback.
- 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
Changed exception data format to match Python's __exit__ format: - exception_type: The exception class name - exception_value: The exception message/value - exception_traceback: The traceback (set to None for now) Updated tests to verify the new data format.
Added proper type hints for parametrized test function parameters to resolve pyright errors.
Use modern type[Exception] annotation instead of deprecated typing.Type.
|
@Kludex ready for another look |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Checklist
Additional context