fix(peer): reject resolving a streamed body more than once

[dinwwwh]

Calling resolveBody() twice on a streamed peer body (event stream or octet stream) now throws TypeError: Failed to read body: body stream already read, like the fetch and node adapters. Before, each call created a new reader of the same message queue. The two readers split the messages between them (one got 0 and 2, the other 1 and 3), and on ServerPeer the second reader could hang forever, because the queue was dropped without being closed.

Fixes

• A second resolveBody() on an event-stream or octet-stream body throws a TypeError, in both ClientPeer (response bodies) and ServerPeer (request bodies). The first reader still gets every message.
• Bodies that are not streamed (JSON, files, form data, URL-encoded) can still be resolved more than once, since they are already in memory.
• ServerPeer now aborts the request body queue when the body finishes, instead of only dropping it, so nothing can be left waiting on it. Before, it only aborted the queue when the body was cancelled.

Testing

• New client and server tests for both stream types check that a second resolveBody() throws, both before and after the stream ends, and that the first reader still receives every message. They fail against main.
• New server tests check that the request body queue is aborted once the body is fully read. They hang against main.
• pnpm run check and pnpm test pass (1336 vitest tests, plus the Bun and Deno suites).

🤖 Generated with Claude Code

https://claude.ai/code/session_012g4ovPb64wru9czTYsrwGe

[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@146

@standard-server/core

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

@standard-server/fastify

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

@standard-server/fetch

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

@standard-server/node

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

@standard-server/peer

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

@standard-server/shared

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

commit: 1b59e60

[codspeed]

Merging this PR will not alter performance

✅ 26 untouched benchmarks
⏩ 108 skipped benchmarks¹

---

_{Comparing claude/brave-tesla-hllbnq (1b59e60) with main (d5d0eb6)}

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. ↩

[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 — full PR (4 files, 4 commits), verified by running the peer suite plus tests/data-transfer.test.ts / tests/signal-and-cancel.test.ts (823 tests passing) and the repo check (sherif/oxlint/oxfmt/tsc).

• Single-read guard for streamed peer bodies — toStandardBody now wraps the event/octet stream resolvers in resolveStreamBodyOnce, so a second resolveBody() throws the same TypeError as the fetch adapter instead of building a second consumer that splits the queue.
• Unconditional request-body queue abort — the server cleanup callback now aborts both queues (was only on cancelled && streamActive) before unsetting them, so a pending pull() on a dropped queue always settles. stream/cancel is still emitted only on cancelled + active.
• Tests — new server/client cases for event- and octet-stream double-resolve, and assertions that the dropped queue rejects with Queue was aborted..

The guard's closure flag and the abort-on-success path are both safe: success/error cleanup only runs after the terminator is consumed, when no legitimate buffered message or pending pull remains, and the atomic/json branches (which don't share a queue) are correctly left unguarded.

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