Users report that long tool calls are often cancelled, and neither the client team nor the server team can explain why. Which practice from the cancellation specification would make these events diagnosable?
Select an answer to reveal the explanation.
Short Explanation
A cancel with no reason is a door slammed in an empty house — you know it happened, not why. The spec asks both sides to log cancellation reasons, and the notification even has a reason field for that. Write it down on both ends and the mystery solves itself.
Full Explanation
The cancellation specification lets a client cancel an in-progress request; on stdio it sends notifications/cancelled with the request ID and an optional reason string that can be logged or displayed, while on Streamable HTTP closing the request's response stream is the cancellation signal. Its implementation notes say both parties SHOULD log cancellation reasons for debugging, and application UIs SHOULD indicate when cancellation is requested. Logging on both sides lets teams correlate client timeouts, user actions and server behavior. Replying with an error is wrong, because servers receiving a cancellation SHOULD stop processing, free resources and not send a response for the cancelled request. Resending with the same id breaks the rule that a request id must not match any other outstanding request from the same sender and would confuse correlation. Servers MUST NOT send notifications/cancelled for any purpose other than tearing down a subscriptions/listen stream, so a confirmation message is not allowed. Exam caveat: cancellation races are normal; a cancel may arrive after processing finished, and both sides must handle that gracefully. Operational check: cancel a test call from the client, then confirm the client log records the reason and request ID and the server log records the same request ID with the cancellation.