fix(server): settle a cancelled probe so a pipelined fallback initial…
Claude / Claude Code Review
completed
Jun 18, 2026 in 22m 37s
Code review found 1 potential issue
Found 2 candidates, confirmed 1. See review comments for details.
Details
| Severity | Count |
|---|---|
| 🔴 Important | 0 |
| 🟡 Nit | 0 |
| 🟣 Pre-existing | 1 |
| Severity | File:Line | Issue |
|---|---|---|
| 🟣 Pre-existing | packages/server/src/server/serveStdio.ts:187-198 |
Pre-existing: Protocol._oncancel falsy requestId check ignores cancellation of request id 0 |
Annotations
Check notice on line 198 in packages/server/src/server/serveStdio.ts
claude / Claude Code Review
Pre-existing: Protocol._oncancel falsy requestId check ignores cancellation of request id 0
Pre-existing issue (not introduced by this PR): `Protocol._oncancel` in `packages/core/src/shared/protocol.ts:512-515` guards with `if (!notification.params.requestId) return`, so a `notifications/cancelled` naming request id `0` — the very first id an SDK client uses — is silently ignored and the in-flight handler is never aborted. The new channel-level settle here correctly checks `cancelledId !== undefined`; a follow-up should change the Protocol guard to `requestId === undefined` so the two
Loading