fix(core): treat relatedRequestId 0 as present in debounce guard (closes #2117)

[adityachilka1]

Closes #2117.

The debounce guard in Protocol.notification() treated relatedRequestId: 0
as absent:

// packages/core/src/shared/protocol.ts
const canDebounce =
    debouncedMethods.includes(notification.method) &&
    !notification.params &&
    !options?.relatedRequestId &&    // ✇ falsy-check eats 0
    !options?.relatedTask;

0 is a valid JSON-RPC RequestId (and is also the first id a Protocol
instance uses for requests). The issue author included a standalone repro that
drives notification() directly and shows the asymmetry:

relatedRequestId	debounced? (pre-fix)
0	YES (bug)
1	no
"0"	no

So two related notifications for request id 0 in the same tick got coalesced
even though related notifications are explicitly supposed to bypass debouncing.

The fix

One-line change: swap the truthy check for a null check (the same fix pattern
the issue author proposed):

         const canDebounce =
-            debouncedMethods.includes(notification.method) && !notification.params && !options?.relatedRequestId && !options?.relatedTask;
+            debouncedMethods.includes(notification.method) && !notification.params && options?.relatedRequestId == null && !options?.relatedTask;

== null catches both null and undefined, and is the idiom the codebase
already uses when preserving 0 as a valid id (e.g. in parallel patches for
#2115 / #2116).

relatedTask is a RelatedTaskMetadata object, so a falsy check is still
correct for it.

Test

Added a regression test should NOT debounce a notification that has relatedRequestId 0 immediately after the existing 'req-1' / 'req-2' test.
It pins that two synchronous calls with 0 each reach the transport (no
coalescing). Without the fix, the test fails (only 1 call reaches the spy).

Verification

cd packages/core && pnpm exec vitest run test/shared/protocol.test.ts

-> 151 / 151 tests passing (the new test is in the 151).

No behavioral regression

The only change is that relatedRequestId: 0 now correctly bypasses debouncing.
All other values (1, "req-1", undefined) hit the same code path as before.

---

(This is a clean pick-up of the issue author's root-cause analysis and
proposed fix - all credit to @tylerklose for the diagnosis.)

[changeset-bot]

⚠️ No Changeset found

Latest commit: d6ef917

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@2141

@modelcontextprotocol/codemod

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/codemod@2141

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@2141

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@2141

@modelcontextprotocol/fastify

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/fastify@2141

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@2141

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@2141

commit: d6ef917