A user clicks Stop, so a stdio client sends notifications/cancelled for request 42. A moment later, the full successful result for request 42 arrives from the server. What should the client do with that late response?
Select an answer to reveal the explanation.
Short Explanation
You told the pizza place to cancel, but the driver was already at your door. It's a race, not a crime — you just don't eat it. The client ignores responses that arrive after it cancelled.
Full Explanation
Cancellation in MCP is a fire-and-forget notification, and network latency means it may reach the server after processing has finished or even after the response was sent. The specification says both parties must handle these race conditions gracefully, and in particular the client should ignore any response to the cancelled request that arrives afterward. The user asked to stop, so delivering the result to the model would act against the user's decision and could trigger follow-up actions the user did not want. The late response is not a protocol violation, since servers may ignore cancellation when processing has already completed; responding with -32603 is also impossible, because clients do not send JSON-RPC responses to results. Repeatedly re-sending notifications/cancelled is wrong, because notifications receive no response, there is no cancellation acknowledgment message, and cancellation notifications must reference only requests believed to still be in progress. Exam caveat: on Streamable HTTP the client cancels by closing the request's response stream, which makes a late response on that stream impossible. Operational check: in a stdio test harness, cancel a request just as it completes and confirm the client drops the late result, logs the cancellation reason, and shows the request as cancelled in the UI.