requestId 0 is silently dropped by _oncancel, making the first request from every Protocol uncancellable

[feldmannn]

Problem

packages/core/src/shared/protocol.ts:411-414:

private async _oncancel(notification: CancelledNotification): Promise<void> {
    if (!notification.params.requestId) {
        return;
    }
    const controller = this._requestHandlerAbortControllers.get(notification.params.requestId);
    controller?.abort(notification.params.reason);
}

The if (!notification.params.requestId) check is falsy on 0. Combined with:

• _requestMessageId = 0 (line 313)
• const messageId = this._requestMessageId++ (line 868, post-increment)

The first outbound request from every Client or Server instance gets wire id 0. A peer notifications/cancelled { requestId: 0 } is silently dropped. The handler runs to completion with ctx.mcpReq.signal.aborted === false.

Both Client and Server extend Protocol, so the bug applies in both directions (peer-cancelling the client's first request, or peer-cancelling the server's first peer-initiated request).

Reproducer

Requires a build from main or the next alpha (InMemoryTransport is not in the 2.0.0-alpha.2 publish; see #1834). The reproducer drives raw JSON-RPC messages so it can pin the wire id to 0:

import { Server, InMemoryTransport } from '@modelcontextprotocol/server';

const [a, b] = InMemoryTransport.createLinkedPair();
const server = new Server({ name: 's', version: '1' }, { capabilities: { tools: {} } });

let observed;
server.setRequestHandler('tools/call', async (req, ctx) => {
    await new Promise(resolve => {
        ctx.mcpReq.signal.addEventListener('abort', () => {
            observed = true;
            resolve();
        }, { once: true });
        setTimeout(() => {
            observed = ctx.mcpReq.signal.aborted;
            resolve();
        }, 500);
    });
    return { content: [{ type: 'text', text: 'done' }] };
});

await server.connect(a);
b.onmessage = () => {};

await b.send({ jsonrpc: '2.0', id: 0, method: 'tools/call', params: { name: 'foo', arguments: {} } });
await new Promise(r => setTimeout(r, 50));
await b.send({ jsonrpc: '2.0', method: 'notifications/cancelled', params: { requestId: 0 } });
await new Promise(r => setTimeout(r, 600));

console.log('observed:', observed); // false (BUG: should be true)

The same script with id: 1 (a non-zero id) cancels in under 50ms.

Proposed fix

if (notification.params.requestId === undefined) {
    return;
}

JSON-RPC permits string ids too, so a defense-in-depth version is === undefined || requestId === null.

[jshaofa-ui]

Root Cause

Classic JavaScript truthy-check bug in packages/core/src/shared/protocol.ts:411-414:

if (!notification.params.requestId) {  // ← BUG: falsy on 0
    return;
}

Combined with _requestMessageId = 0 (initial value) and post-increment, the first outbound request from every Protocol instance gets wire ID 0. A peer's cancel notification for requestId 0 is silently swallowed — making the first request from every client/server permanently uncancellable.

Proposed Fix

private async _oncancel(notification: CancelledNotification): Promise<void> {
    const requestId = notification.params.requestId;
    if (requestId === undefined || requestId === null) {
        return;
    }
    const controller = this._requestHandlerAbortControllers.get(requestId);
    controller?.abort(notification.params.reason);
}

Impact

• First request from every client/server is uncancellable
• Resource leaks when server handlers hang (can never be aborted)
• Compounds with connection pooling (each new connection = new Protocol = new requestId 0 that's uncancellable)

Files to Modify

1. packages/core/src/shared/protocol.ts — _oncancel method (line ~411)

Test Case

it('should handle cancel notification with requestId 0', async () => {
    const controller = new AbortController();
    protocol._requestHandlerAbortControllers.set(0, controller);
    await protocol._oncancel({
        jsonrpc: '2.0', method: 'notifications/cancelled',
        params: { requestId: 0, reason: 'test' }
    });
    expect(controller.signal.aborted).toBe(true);
});

Full solution: solutions/mcp-typescript-sdk-2115-requestid-zero-dropped-fix.md

[Ilya0527]

if (!notification.params.requestId) is the canonical zero-as-falsy bug — 0 is a valid wire id in JSON-RPC and gets coerced to false by !. The fix is one character per check site:

if (notification.params.requestId == null) {  // both null and undefined; NOT zero
    return;
}

Or, equivalently and slightly more explicit:

if (notification.params.requestId === undefined || notification.params.requestId === null) {
    return;
}

Both Client and Server extending Protocol is the part that makes this a higher-leverage bug than it looks — every Protocol instance has exactly one wire-id-0 request, and that one is structurally uncancellable. The asymmetry is: in long-running sessions, the first request is often the most important one to be able to cancel (initial connection probe, setup tool call, the user's first command).

Two refinements worth considering once the immediate fix lands:

1. Audit _requestMessageId initialization. Starting at 0 and pre/post-incrementing is correct, but a quick scan for other if (!someId) patterns elsewhere in the SDK that consume requestId values would catch the rest of this class — JSON-RPC's wire IDs being valid at zero is a contract the whole codebase has to honor consistently. The relatedRequestId 0 is treated as absent companion issue (relatedRequestId 0 is treated as absent by notification debounce guard #2117 if I read the issue tracker correctly) suggests there's at least one more instance.

2. Type-system defense. If requestId is typed as number | string, a zero-number is indistinguishable from "set but falsy." A wrapper type like RequestId = Branded<number | string, 'RequestId'> with a RequestId.isPresent(x): x is RequestId predicate makes the absent-vs-zero distinction encodable, and if (!rid) becomes a type error. Heavier change; closes the bug class permanently.

For a clean repro that doesn't depend on InMemoryTransport (which isn't shipped in the alpha), driving raw JSON-RPC over a MessageChannel works — both endpoints share the same process so you can pin messageId: 0 deterministically without a transport hop. Worth offering as a less-build-dependent alternative when filing the test.