fix(client): abort legacy SSE reconnect chain when the originating request times out - #2616
Open
claude[bot] wants to merge 17 commits into
Open
fix(client): abort legacy SSE reconnect chain when the originating request times out#2616claude[bot] wants to merge 17 commits into
claude[bot] wants to merge 17 commits into
Claude / Claude Code Review
completed
Aug 6, 2026 in 13m 48s
Code review found 1 important issue
Found 5 candidates, confirmed 5. See review comments for details.
Details
| Severity | Count |
|---|---|
| 🔴 Important | 1 |
| 🟡 Nit | 2 |
| 🟣 Pre-existing | 2 |
| Severity | File:Line | Issue |
|---|---|---|
| 🟡 Nit | .changeset/legacy-sse-reconnect-after-timeout.md:1-5 |
Changeset under-documents server-side wire change and onerror-contract changes |
| 🟣 Pre-existing | packages/core-internal/src/shared/protocol.ts:1485-1497 |
_oncancel falsy guard drops notifications/cancelled for request id 0 |
Annotations
Check warning on line 5 in .changeset/legacy-sse-reconnect-after-timeout.md
claude / Claude Code Review
Changeset under-documents server-side wire change and onerror-contract changes
The changeset under-documents two consumer-observable behavior changes this PR ships: (1) it names only `@modelcontextprotocol/client`, but the maxTotalTimeout cancel reroute lives in the shared Protocol layer bundled into `@modelcontextprotocol/server` too — a server-initiated request (createMessage/elicitInput/requestSampling with `maxTotalTimeout` + `resetTimeoutOnProgress`) that trips the budget now POSTs `notifications/cancelled` where pre-PR nothing went on the wire, so the server CHANGELO
Check notice on line 1497 in packages/core-internal/src/shared/protocol.ts
claude / Claude Code Review
_oncancel falsy guard drops notifications/cancelled for request id 0
Pre-existing issue (the flagged line is untouched by this PR): `Protocol._oncancel` opens with `if (!notification.params.requestId) return;` — a falsy guard for the optional-absent case that also swallows the legitimate JSON-RPC id `0`. Since `_requestMessageId` starts at 0, every SDK peer's first outbound request has id 0, so a `notifications/cancelled` for a connection's first request is silently dropped by the receiving SDK peer — including the exact `requestId: 0` payload this PR's new maxTo
Loading