feat(core): restore v1 Zod-schema overloads on setRequestHandler/setNotificationHandler/request - #1891
Closed
felixweinberger wants to merge 14 commits into
Closed
feat(core): restore v1 Zod-schema overloads on setRequestHandler/setNotificationHandler/request#1891felixweinberger wants to merge 14 commits into
felixweinberger wants to merge 14 commits into
Claude / Claude Code Review
completed
Apr 27, 2026 in 33m 48s
Code review found 1 potential issue
Found 1 candidates, confirmed 1. See review comments for details.
Details
| Severity | Count |
|---|---|
| 🔴 Important | 0 |
| 🟡 Nit | 1 |
| 🟣 Pre-existing | 0 |
| Severity | File:Line | Issue |
|---|---|---|
| 🟡 Nit | packages/client/test/client/setRequestHandlerSchemaParity.test.ts:71-72 |
Client sampling parity test uses loose 'Invalid' assertion |
Annotations
Check warning on line 72 in packages/client/test/client/setRequestHandlerSchemaParity.test.ts
claude / Claude Code Review
Client sampling parity test uses loose 'Invalid' assertion
This assertion only checks `.toContain('Invalid')`, which would also be satisfied by `'Invalid sampling request: …'` (client.ts:442, the request-validation path) — so if a future change made `{messages:[], maxTokens:1}` fail `CreateMessageRequestSchema`, the test would pass without ever reaching the result-validation wrapper it's meant to guard. The sibling elicitation test (line 57) and the server-side parity test (tightened in d2e046d6 per the same review feedback) already use the specific res
Loading