[dinwwwh]

Problem

isClientPeerSendMessage and isServerPeerSendMessage were typed (maybe: PeerMessage) and only checked kind and json. They assumed the caller had already run isPeerMessage, which checks:

• the value is an object
• id is a string
• kind is a string
• binary is undefined, a Uint8Array or a Blob

Nothing at runtime enforces that ordering. TypeScript doesn't catch it either when the input is any, as JSON.parse output is. A caller that validates raw input with one of these guards alone:

• accepts a message whose id is true, {}, [], null, a number, or missing;
• accepts a binary that isn't binary, such as a string or a plain object;
• gets a TypeError: Cannot read properties of null (reading 'kind') on null, instead of false.

This happened in oRPC's HTTP batch plugins, fixed downstream in middleapi/orpc#2304:

• On the server, a non-string id ran the procedure and was echoed back in the response. A deeply nested array id (~20KB body) made JSON.stringify throw RangeError: Maximum call stack size exceeded outside every interceptor.
• On the client, a JSON object in binary resolved the call with a "[object Object]" file.

The same mistake is easy to repeat in any new caller that handles raw input.

Fix

Both combined guards now take unknown and run isPeerMessage first. They are safe to call directly on untrusted input, and they behave the same when given a real PeerMessage.

The per-kind guards (isPeerRequestMessage, isPeerResponseMessage, …) stay typed PeerMessage. They are the building blocks the combined guards call after narrowing, and their signature already states what they expect.

Compatibility

• Types: widening the parameter from PeerMessage to unknown is non-breaking for callers. Existing code that passes a PeerMessage, such as the output of decodePeerMessage, compiles and narrows as before.
• Runtime: the only change is that values isPeerMessage rejects now return false. Before, they could return true, or throw for null. The internal client and server code doesn't call these guards. decodePeerMessage already runs isPeerMessage, so for messages that come from it the extra check costs a few property reads.

Tests

validators.test.ts adds cases to both guards for a non-string id, a string binary, null, and an array. Six of the eight fail on main: two are wrongly accepted and one throws a TypeError, for each guard.

• pnpm test: 1382 vitest tests and 52 bun tests passed
• pnpm run check: sherif, oxlint, oxfmt and tsc all pass

---

Generated by Claude Code

[pkg-pr-new]

• @standard-server/hono-node-playground
• @standard-server/node-http-playground

@standard-server/aws-lambda

npm i https://pkg.pr.new/@standard-server/aws-lambda@172

@standard-server/core

npm i https://pkg.pr.new/@standard-server/core@172

@standard-server/fastify

npm i https://pkg.pr.new/@standard-server/fastify@172

@standard-server/fetch

npm i https://pkg.pr.new/@standard-server/fetch@172

@standard-server/node

npm i https://pkg.pr.new/@standard-server/node@172

@standard-server/peer

npm i https://pkg.pr.new/@standard-server/peer@172

@standard-server/shared

npm i https://pkg.pr.new/@standard-server/shared@172

commit: e258fda

[macroscopeapp]

Approvability

Verdict: Approved at e258fda

Macroscope's review found this PR approvable — This PR hardens the client/server peer send-message guards by validating the common message shape before subtype checks, while preserving behavior for valid messages. It adds focused tests for malformed inputs and has no broader runtime, schema, deployment, or infrastructure changes.

^{You can add or adjust custom eligibility rules. Learn more.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[pullfrog]

✅ No new issues found.

Reviewed changes

• Combined guards now validate the envelope first — isClientPeerSendMessage and isServerPeerSendMessage take unknown and call isPeerMessage(maybe) before the per-kind || chain, so raw input with a non-string id, a non-binary binary, a non-object, or null now returns false instead of wrongly accepting or throwing.
• Per-kind guards left as-is — isPeerRequestMessage, isPeerResponseMessage, etc. stay typed PeerMessage; they run after the narrowing and their signatures already state the precondition.
• Regression tests added — validators.test.ts gains an it.each block per combined guard covering non-string id, string binary, null, and array.

I confirmed the new cases are discriminating: reverting only validators.ts to base 6f1fc5a fails 6 of the 8 (both guards wrongly accept a non-string id and a string binary, and both throw TypeError on null), matching the PR description. The parameter widening PeerMessage → unknown is non-breaking, and the only in-repo callers pass decodePeerMessage(...).message, which already runs isPeerMessage, so behavior is unchanged for real messages.

  ^{｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}

[codspeed]

Merging this PR will not alter performance

1 warning

⚠️ 4 benchmarks are dominated by system calls

System calls cannot be simulated consistently and are left out of the measure. The reported value understates the real cost. Switch to the Walltime instrument to measure them.

Learn more about system calls

See affected benchmarks

✅ 26 untouched benchmarks
⏩ 108 skipped benchmarks¹

---

_{Comparing claude/peer-send-guards-check-peer-message (e258fda) with main (fc31c9d)²}

Footnotes

1. 108 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on main (6f1fc5a) during the generation of this report, so fc31c9d was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩