Skip to content

refactor(core): wire-layer/public-layer full separation — frozen per-era schemas, function-only WireCodec, bidirectional lint rule - #2351

Merged
felixweinberger merged 11 commits into
v2-2026-07-28from
fweinberger/wire-public-separation
Jun 24, 2026
Merged

felixweinberger merged 11 commits into
v2-2026-07-28from
fweinberger/wire-public-separation

refactor(core): restore deprecated Task* schemas to neutral layer

cdaf056
Select commit
Loading
Failed to load commit list.
Claude / Claude Code Review completed Jun 24, 2026 in 27m 51s

Code review found 3 potential issues

Found 5 candidates, confirmed 3. See review comments for details.

Details

Severity Count
🔴 Important 0
🟡 Nit 2
🟣 Pre-existing 0
Severity File:Line Issue
🟡 Nit packages/server/src/server/listenRouter.ts:79-84 parseListenFilter rejects valid filters when an unrelated params member fails the whole-request codec parse, with a misl
🟡 Nit packages/server/src/server/server.ts:1006-1019 Server.createMessage double-parses the sampling result (registry wide parse + samplingResultVariant); _requestWithSchema

Annotations

Check warning on line 84 in packages/server/src/server/listenRouter.ts

See this annotation in the file changed.

@claude claude / Claude Code Review

parseListenFilter rejects valid filters when an unrelated params member fails the whole-request codec parse, with a misleading -32602 message

Routing parseListenFilter() through the whole-request codec parse (validateRequest('subscriptions/listen', message)) means a listen request with a perfectly valid notifications filter but a malformed unrelated params member (e.g. _meta.progressToken: true) now fails entirely and both call sites answer -32602 with the hard-coded message blaming 'notifications' — pre-PR this function only parsed params.notifications and accepted such requests. Either scope the validation to params.notifications or

Check warning on line 1019 in packages/server/src/server/server.ts

See this annotation in the file changed.

@claude claude / Claude Code Review

Server.createMessage double-parses the sampling result (registry wide parse + samplingResultVariant); _requestWithSchema JSDoc now stale

Server.createMessage now validates the sampling result twice: the schema-less `this.request()` path parses the raw result with the 2025 registry entry (`CreateMessageResultWithToolsSchema`), and `samplingResultVariant(hasTools, wide)` immediately re-parses the same value — byte-identical schema in the with-tools case — so every server-initiated sampling exchange runs two full Zod parses (sampling results can carry large base64 content through the `atob` refine), and validation failures now split