Server: a notifications/cancelled that arrives before the request's handler task is registered is dropped, so the request runs to completion #285

Summary

Server registers a request's handler task for cancellation after it has already returned to the receive loop, so a notifications/cancelled that follows the request closely enough is processed before the registration exists. The cancellation is then logged as "unknown or completed" and ignored, and the request runs to completion and sends its response — for a request the server has, in fact, received and is about to start.

Mechanics (0.12.1, Sources/MCP/Server/Server.swift)

1. The receive loop decodes a request and hands it off without waiting (:235):

   } else if let request = try? decoder.decode(AnyRequest.self, from: data) {
       // Handle request in a separate task to avoid blocking the receive loop
       Task {
           _ = try? await self.handleRequest(request, sendResponse: true)
       }
   }

   The loop immediately continues to the next stream element.
2. Inside that task, handleRequest first awaits the transport's HTTP context lookup (:784) and only then registers the task (:816):

   pendingRequestTasks[request.id] = handlerTask

3. Meanwhile the loop has already decoded the next element. If it is notifications/cancelled for that id, the built-in handler runs removePendingRequest(id:) (:1001), finds nothing, and takes the "unknown or completed" branch. Nothing cancels the handler task once it is registered a moment later.

The window is the gap between the detached Task at :235 and the assignment at :816, which includes an await. It is a real ordering hazard, not a theoretical one: any client that sends a request and cancels it immediately (a user abort, a timeout that fires during send) can hit it, and it is deterministic to reproduce with a barrier that holds the context lookup until the cancellation has been consumed.

Expected behavior

The cancellation spec says the receiver SHOULD stop processing the cancelled request and not send a response, and MAY ignore a cancellation for an unknown request. This request is not unknown — the server decoded it and dispatched it — so ignoring the cancellation is a missed SHOULD caused by an implementation race, not a legitimate "unknown request" case. A cancellation that arrives after dispatch and before registration should still cancel the request, or prevent the handler from starting.

Reproduction

On any transport (stdio, or two back-to-back stateless HTTP POSTs), send:

1. {"jsonrpc":"2.0","id":"r1","method":"tools/call","params":{"name":"slow"}}
2. immediately: {"jsonrpc":"2.0","method":"notifications/cancelled","params":{"requestId":"r1"}}

Observe: the slow handler runs and a response for r1 is sent. With a transport whose httpRequestContext(for:) is held until after the cancellation is consumed, the outcome is deterministic.

Existing fix

PR #270 (Fix early request cancellation race) addresses exactly this: it tracks the dispatch task before handler registration so an immediate cancellation cannot fall through the gap, processes the built-in cancellation handler before other notification handlers can suspend, and adds a deterministic barrier test (Cancellation received before handler registration prevents handler start). That PR currently references no issue; this one is filed so the defect has a tracking entry independent of any particular fix. #270 also carries two adjacent hardening changes — suppressing a late response from a handler that swallows CancellationError, and rejecting duplicate outstanding request ids in Server — which are worth noting when reviewing it, since the second is a behavior change beyond this bug.

Related

• StatelessHTTPServerTransport: notifications/cancelled leaves the original POST hanging (HTTP exchange never completed) #255 — a cancelled request's HTTP POST hangs in StatelessHTTPServerTransport (the transport side of cancellation; fix in fix: StatelessHTTPServerTransport leaves the original POST hanging after notifications/cancelled (#255) #260)
• StatelessHTTPServerTransport: concurrent requests sharing a JSON-RPC id overwrite each other's response waiter (hang + continuation leak) #254 / StatelessHTTPServerTransport keys per-request HTTP context by client-chosen JSON-RPC id — concurrent clients with colliding ids can observe each other's HTTPRequest (including Authorization) #265 — colliding JSON-RPC ids across concurrent stateless clients (fix in fix: isolate stateless HTTP request exchanges #264); with exchange-scoped ids in place, Server's duplicate-id rejection from Fix early request cancellation race #270 only ever triggers on single-client transports