Session validation error

[moldhouse]

This PR adds exception handling to validation of incoming grpc requests in the session.

Motivation and Context

While the public interface of the session (e.g. session.send_request) makes assumptions about the data types send to the session, the StreamableHttpServerTransport does not use this, and rather sends data directly to the channel. Therefore, the validation of the incoming data in the receive loop of the session may fail. This can be integration tested by sending an invalid method to the server, which crashes the task of the particular session.

How Has This Been Tested?

I added a unit test on the session level that verifies that the session is unresponsive after a bad input. Construction of the session in the test feels a bit awkward, and there might be better ways to test this particular piece of code. One refactor idea might be to move the logic in the session loop to a separate method to better unit test it.

Breaking Changes

This change does not break any public apis. It does however change behaviour, in that the server does not crash on invalid messages, but swallows them, similar how it is already happening for notifications which can not be validated.

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

[felixweinberger]

Hi @moldhouse thank you for this contribution! And apologies for the time it took to get back to you on this.

This change does seem to address crashing but it would be great if we could maintain compliance with the JSON-RPC 2.0 spec.

When a request with an ID fails validation, the server MUST send an error response (code -32600). Currently as you said, it only logs internally and continues, i.e. swallows the error without feedback to the client.

Would be great if we could send back something like ErrorData(code=INVALID_REQUEST, message="Invalid request") via _send_response in the exception case.

[felixweinberger]

we should send back some feedback about invalid request to the client here (and update the tests to check for that)

[felixweinberger]

Looks like this should already be addressed by #967, hence closing this one to clean up our backlog.

Thank you again for this contribution!