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.

[jmrplens]

Rebased onto current main (55350a9). It was conflicting against internal/jsonrpc2/conn.go and mcp/transport.go, both of which #1255 touched when it merged, so the conflict was between this change and my own.

Two of the three resolutions are worth stating, because they are decisions rather than mechanics.

CancelFromPeer now takes a cause. #1255 added Connection.CancelCause, which records why a request's context was cancelled so the handler can read it back through context.Cause, and this PR added CancelFromPeer, which suppresses the response. Both were variants of Cancel and the merged body wanted both values, so all three now delegate to one cancelIncoming(id, cause, fromPeer). Composing them this way rather than picking one is what the two changes are each about: a peer cancellation is precisely the kind that arrives with a stated reason, so canceller.Preempt both logs the reason and passes it as the cause, and the request is still answered with no response.

TestCancellationReason needed a change, and the reason is this PR's behaviour rather than the rebase. That test sends notifications/cancelled by hand and never retired the outgoing call, which was harmless while the receiver still answered a cancelled request. With no response it waits forever and synctest reports the bubble as deadlocked. The SDK's own cancel path already retires the call before it notifies (cancelCall in mcp/transport.go), precisely because a peer that cancels is not waiting for a result, so the test now does the same thing explicitly. That it surfaced here is the interaction working as intended: the test encoded an assumption this change is removing.

go build ./..., go vet ./... and go test ./... are clean on the rebased tree.

[guglielmo-san]

i think in case of empty data, so peer cancelled request, it should return 204 as code

[jmrplens]

Agreed, and done in 1faac54, rebased onto main.

A stream that ends with nothing written on it now answers the POST with 204 No Content and no Content-Type: in JSON mode there is nothing to flush, and in SSE mode the header is likewise still unsent when no event was ever written (lastIdx < 0), so both get the 204 rather than an empty 200 under a Content-Type; a stream that already carried something ends as before. TestStreamableCancelledCallGetsNoResponse runs in both modes and asserts the status, the missing Content-Type and the empty body; the protocol doc says so too.

The SDK client itself never reads it, since its POST is cancelled together with the call. A client that keeps the POST open while cancelling from another request reads a 204 with no body, which is what "no response" looks like on the wire.