modelcontextprotocol
Sending cancellation notification to server based on client anyio.CancelScope status
Motivation and Context
MCP 2025-03-26 introduces a cancellation notification [1] this patch simplifies the usage of this function for the ClientSession by using the anyio.CancelScope as a trigger to send the cancellation notification and is a potential fix for https://github.com/modelcontextprotocol/python-sdk/issues/160
How Has This Been Tested?
Added unit tests to assert behaviour and tidied up previous work around for lack of this behaviour in tests/shared/test_session.py#test_request_cancellation
Breaking Changes
This patch sends a CancelNotification to any in flight requests to the server at the point the client is cancelled. Clients that would have expected calls to complete on the server regardless of status of cancel scope on the client will need to be updated.
As a work around for any clients where this behavior is not desired this patch adds a cancellable flag to send_request and call_tool to enable clients to opt out of this behaviour so server tasks must respond prior to exitting.
This cancellable=False behaviour is required for the initialised call from the client as described in [1] though this does open up a raft of questions on what is supposed to happen if the initialised call blocks on the server. A timeout on the client might be appropriate however this opens up follow on questions on what subsequent behaviour should be after an initialisation timeout.
This approach of a breaking change is suggested as author expects in general most clients would prefer to cancel an expensive server tasks if client is cancelled and initialisation tasks are expected to be quick and non-blocking on the server.
Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [x] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] Documentation update
Checklist
- [x] I have read the MCP Documentation
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
Additional context
I've added a docstring to describe the behaviour to send request. I suspect wider documentation updates would be sensible, I'm happy to write something if this patch looks useful.
It might also be useful to separate out the idea of client cancelation with server cancelation such that a client can cancel its work but leave the server task running. Comments on the pull request on the best approach is probably necessary.
[1] https://modelcontextprotocol.io/specification/2025-03-26/basic/utilities/cancellation
Also potential fix for https://github.com/modelcontextprotocol/python-sdk/issues/230
Note the failed check above appears to be due to: https://github.com/modelcontextprotocol/python-sdk/issues/744
I'm going to explore whether this is better implemented as part of behaviour specified in https://github.com/modelcontextprotocol/modelcontextprotocol/pull/617
