[EhsanAzish80]

This brings together #264, #260, and #270. Stateless HTTP requests get separate internal IDs, while each response keeps the client's original ID. Cancellation reaches the matching handler before the HTTP exchange ends, and a late handler result cannot send a second response.

Following the review discussion, an ambiguous cancellation ID leaves the active requests alone. A duplicate outstanding ID is rejected only when it is a genuine conflict. For the 2025 HTTP path, the cancellation POST returns 202 and the original POST ends as HTTP 200 with an empty SSE stream, without a JSON-RPC response. This wire behavior needs maintainer review before merge. This change does not add a default SDK timeout.

The HTTP adapter owns the result when it cancels an exchange, including timeouts and disconnects. In-flight requests ended by server shutdown now complete with HTTP 503 instead of a generic 500.

Local checks passed: 565 Swift tests in 41 suites, plus a real HTTP loopback check for cancellation, cleanup, and server shutdown. CI is awaiting maintainer approval on this revision.

Tests were written with AI help.

[soyeladice-svg]

The updated head still completes a cancelled MCP request by synthesizing a JSON-RPC error:

AnyMethod.response(
    id: waiter.originalID,
    error: .serverError(code: -32800, message: message)
)

That looks inconsistent with the cancellation contract. For notifications/cancelled, MCP says receivers SHOULD stop processing, free resources, and not send a response for the cancelled request.

I agree the HTTP exchange itself must not hang, but those are separable requirements. The transport can terminate the POST without producing a JSON-RPC response associated with the cancelled request — e.g. 204/no body when nothing has been committed — while still forwarding the cancellation so the handler stops.

Could completeCancelledExchange finish the waiter with an HTTP no-content outcome rather than fabricating -32800, and update the tests to assert an empty response body? That would preserve the transport liveness fix without changing MCP-level cancellation semantics.

AI-assisted review; re-checked this against the updated 2c3e81b head before posting.

[EhsanAzish80]

I pushed a follow-up for the cancellation review: the original POST now ends as a 200 empty SSE stream, without a synthetic JSON-RPC error. This changes our earlier -32800 choice, so I’d like a maintainer call on the wire behavior before merge. All 565 Swift tests passed locally, plus a real HTTP client/server cancellation check. AI helped write the new tests; I ran them. Could a maintainer review this and approve CI?

[varun06]

Thanks @EhsanAzish80. Consolidating #260/#264/#270 into one design is the right call, and the routing
looks solid. The suite passes locally, and I ran the cancellation and HTTP server suites 10× with no flakes.

One required change:
Only change the id, not the whole body. routingRequest/restoringResponseID re-serialize every
request and response with JSONSerialization, which rewrites payload data. With the exact options in the PR:

• "id": true is accepted as number(1) (JSON-RPC ids must be strings or numbers)
• tool arguments 0.1 → 0.10000000000000001, 19.99 → 19.989999999999998, 0.3 → 0.29999999999999999
  The response side would rewrite numbers in every tool result sent to clients. A Codable round trip
  (JSONDecoder → JSON value → JSONEncoder) keeps these exactly. Could you patch just the id that way
  (or splice the top-level "id"), and reject ids that aren't strings or integers?
  On the wire-format question: an empty SSE stream is the cleanest "no JSON-RPC response", but this
  transport accepts Accept: application/json alone (AcceptHeaderValidator(mode: .jsonOnly)). I'd return
  the empty SSE stream when Accept includes text/event-stream and fall back to a JSON-RPC error otherwise.

Smaller points:

• Rejecting a duplicate outstanding id sends an error with that same id, so the client matches it to the
  original request and drops the real response later. Since duplicates violate the spec, logging and
  ignoring may be safer; either way, worth documenting.
• When the HTTP caller goes away, cancelWaitingExchange frees the exchange but the handler keeps running;
  calling cancelRequest(id:) for the routed id would stop it.
• The .response and .notification cases have identical bodies now.
• Release-note material: cancelled requests no longer get a response on any transport.