A cancelled request is still answered

The cancellation utility says that receivers of notifications/cancelled SHOULD "Stop processing the cancelled request", "Free associated resources" and "Not send a response for the cancelled request" (2025-06-18 cancellation, behavior requirement 3; the wording is unchanged in 2025-11-25 and 2026-07-28). The SDK does the first two and never the third. A cancelled call is always answered, on every transport, and a server built on the SDK has no way to stop it.

The response is written in processResult, internal/jsonrpc2/conn.go:

writeErr := c.write(notDone{req.ctx}, response)

notDone is a context wrapper whose Done channel is nil, so the cancellation is deliberately stripped and the write goes ahead. That is right for a handler whose context ended for some other reason, and it is also the only path a cancelled call takes. A peer's cancellation arrives at canceller.Preempt in mcp/transport.go, which calls jsonrpc2.Connection.Cancel for the request id; that cancels the handler's context and records nothing else, so by the time processResult runs nothing distinguishes "the peer cancelled this id" from "this context ended". Between the handler returning and the write there is no application code, no receiving middleware and no transport hook, so the response cannot be suppressed from outside the SDK.

Reproduction

Any server with a tool that blocks until its context ends, over stdio. Write these four messages to its stdin:

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"c","version":"1"}}}
{"jsonrpc":"2.0","method":"notifications/initialized"}
{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"slow","arguments":{}}}
{"jsonrpc":"2.0","method":"notifications/cancelled","params":{"requestId":2,"reason":"User requested cancellation"}}

stdout carries a response for the cancelled request:

{"jsonrpc":"2.0","id":2,"error":{"code":0,"message":"context canceled"}}

I first saw this on a live session rather than a contrived one: the client's notifications/cancelled at 6.306s, and the server's response to that same request id at 6.307s.

The streamable HTTP transport does the same thing, writing the response as an SSE event on the stream that the tools/call POST is holding open:

event: message
data: {"jsonrpc":"2.0","id":2,"error":{"code":0,"message":"context canceled"}}

What it costs

A server written with this SDK cannot satisfy requirement 3 and cannot be made to. The usual escape hatch does not apply: a receiving middleware wraps the method handler, and the response is built and written after that handler has returned, so a middleware can change what the response says but not whether one is sent. A server author who wants to conform is left with nothing to reach for.

I want to answer one objection ahead of time, because it was my own first thought. Behavior requirement 5 says the sender of the cancellation "SHOULD ignore any response to the request that arrives afterward", and the Timing Considerations section explains why: a cancellation may arrive after the response was already sent, and both parties must handle that race gracefully. That is a rule about a race. It is not a licence for the receiver to observe the cancellation, stop processing, free the resources and then answer anyway, which is what happens here every single time. Requirement 3 is about exactly that case, and the two sit in the same list because they cover different ones.

Version

Observed with v1.7.0. The same line is present at v1.8.0-pre.2 and on main at 5bc078a, internal/jsonrpc2/conn.go:718.

I have a fix and will open a pull request for it.

I found this auditing my own server against the specification, the same pass that produced #1254.

Part of #1257.

Reproduce the stdio sequence in the issue, then read processResult in internal/jsonrpc2/conn.go and canceller.Preempt in mcp/transport.go. Trace how jsonrpc2.Connection.Cancel reaches the response write across stdio and streamable HTTP. Done means a peer-cancelled request produces no response while other context-ending requests retain their existing behavior.