mcp: send no response for a request the peer cancelled

[jmrplens]

The MCP cancellation utility says a receiver of notifications/cancelled SHOULD stop processing the request, free its resources, and "Not send a response for the cancelled request". This SDK does the first two and always does the opposite of the third, on every transport: processResult in internal/jsonrpc2/conn.go writes the response with c.write(notDone{req.ctx}, response), and nothing at application level runs between a handler returning and that write, so no server built on the SDK can satisfy the clause.

notDone is there on purpose and this change leaves it alone. A response must still be written when a handler's context ended for some other reason. What the spec asks for is narrower: no response when the peer asked for this particular id to be cancelled. The jsonrpc2 layer could not express that, because Connection.Cancel has two callers that mean different things, canceller.Preempt, which has just read the peer's notification, and ServerSession.Close, which cancels in-flight subscriptions/listen handlers to unblock them so the connection can drain. So the change records the distinction rather than inferring it: Connection.CancelFromPeer marks the incoming request, processResult writes no response for a request so marked, and Cancel keeps its old meaning.

The mark is written and read under the connection's stateMu, in the same critical section that removes the request from incomingByID. A cancellation arriving once the response has been handed to the writer therefore finds nothing to mark, and a response already on its way is never retracted. That is the race the spec's Timing Considerations section describes, and it stays resolved exactly the way it is today.

Suppressing the write on its own would have traded a spec deviation for a hang. The streamable HTTP transport keeps a POST's stream open until every call it carried has been answered, so a response that never arrives leaves that HTTP request open until the client goes away. A Writer that holds per-call state can now implement jsonrpc2.ResponseDropper and be told the response is not coming; streamableServerConn implements it by retiring the request through the same accounting a real response goes through, so the stream completes exactly as it would have. Writers with no such state, stdio and the in-memory transport among them, implement nothing and are unaffected.

Tests

TestStreamableCancelledCallGetsNoResponse (mcp) drives the whole path over raw HTTP: initialize, a tools/call whose tool parks on ctx.Done, notifications/cancelled for that id on a second request, then a read of the call's stream to EOF. It asserts that the stream carries nothing and that it ends. On main it fails with the response the server sent. It fakes the client with raw HTTP rather than using a ClientSession deliberately: an SDK client abandons the POST as soon as it cancels, so it never sees what the server wrote on that stream, and a stream that never completes looks to it exactly like one that did. I checked the other half of the test as well, by keeping the suppression and removing DropResponse: the same test then fails the other way, on the POST never returning.

TestCancelFromPeerSuppressesResponse (internal/jsonrpc2) pins the distinction itself. A second call acts as the barrier, since handlers run one at a time: a peer-cancelled call is answered only by the barrier's response and is reported to the dropper, while a locally cancelled one is still answered.

TestLoggingConnDropResponse (mcp) covers the one wrapper in the way. A connection asks its writer for ResponseDropper, and loggingConn is the only Connection wrapper in the package, so a LoggingTransport around a streamable server would have passed the type assertion straight through to nothing: the response suppressed, the POST's stream left open until the client went away. It now forwards to the delegate when the delegate implements the interface, and does nothing when it does not.

gofmt -l . is clean, go vet ./... is clean, go test ./... passes, and so does go test -race ./internal/jsonrpc2/ ./mcp/.

What an existing user sees change

• A server no longer answers a call whose cancellation it received and acted on. A client that sends notifications/cancelled and then keeps awaiting that id will wait forever. No client in this repository does: both call and cancelCall retire the call locally when they send the notification, so the SDK's own client never waited for that response.
• A subscriptions/listen the client cancels no longer produces the empty SubscriptionsListenResult, because a client cancels a listen by sending notifications/cancelled for the listen's request id. A listen ended by ServerSession.Close still produces it, since that path calls Cancel, not CancelFromPeer. This one is a judgement call: I read the spec as meaning that a cancelled request gets no response at all, completion result included, but the listen handler could be exempted if you read it the other way.
• In JSON response mode a POST whose only call was cancelled now ends 200 with an empty body instead of one carrying the cancelled call's error. The Content-Type is still application/json, which is worth saying out loud: the response claims a JSON body and carries none. Answering 202 Accepted with no content type would read better to a strict client, and I will change it to that if you prefer. This path has no test of its own, unlike the SSE one; say the word and I will add it.
• No exported API is added. CancelFromPeer and ResponseDropper are both in internal/jsonrpc2.

Other judgement calls

• DropResponse takes no context and returns no error. There is nothing to send, and a failure could only ever mean "the stream is already gone", which is the state the call is trying to reach anyway.
• The malformed-result branch of processResult is reordered so that nothing is lost: a handler that returns a result which fails to marshal is still reported through internalErrorf exactly as before, whether or not the call was cancelled. Only the write is skipped.
• I did not put this behind a flag. mcpgodebug already gates two behaviour changes of roughly this shape (blockingcancelnotify, nomethodnotfoundcodeinerror), so if you would rather the old behaviour stayed reachable while callers adjust, say so and I will add one.
• The docs/protocol.md cancellation section gains two sentences. I edited internal/docs/protocol.src.md and the generated file together rather than running weave, since the generator fetches golang.org/x/example; the text is plain prose with no directives, so regenerating reproduces it.

Fixes #1259.