[dinwwwh]

When ClientPeer.request() was called with a signal that was already aborted, the request rejected but its body was never cleaned up. A ReadableStream body was never cancelled, and an async iterator body never ran its return(), so any resources behind it stayed open. That body is now released with the abort reason, the same way as when the request ends before sending for any other reason.

Fixes

• An already-aborted signal now cancels a ReadableStream request body with the abort reason, and returns an async iterator body.
• The request still rejects with the signal's reason, nothing is sent, and no request state or abort listener is left behind.
• A body that fails to clean up is still ignored, since the request has already settled.

Performance

• No change to the success path. An aborted request is still rejected before its body is encoded.

Testing

• Two new client tests, one for each body type, both fail against main.
• vitest run packages/peer (254 passed), eslint, and tsc -b are clean.

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

@standard-server/core

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

@standard-server/fastify

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

@standard-server/fetch

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

@standard-server/node

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

@standard-server/peer

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

@standard-server/shared

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

commit: 7666369

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[codspeed]

Merging this PR will not alter performance

✅ 26 untouched benchmarks
⏩ 108 skipped benchmarks¹

---

_{Comparing claude/peer-client-abort-leak-39b5ce (7666369) with main (28db1dd)}

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

[pullfrog]

✅ No new issues found.

Reviewed changes

• packages/peer/src/client.ts — move the abort check into the transmit path. request() no longer calls throwIfAborted(signal) synchronously; the check moves to the first statement of transmitRequest's try (before encodeAtomicStandardBody). A pre-aborted signal now flows through the existing catch → closeById rejection and the pre-existing finally → cancelStandardBody, releasing a ReadableStream body or returning an async-iterator body. This reuses the same cleanup path already exercised by abort-during-encode/send, peer close, and send failure.
• packages/peer/src/client.test.ts — two regression cases. One per body type under signal / abort, asserting the body is released with the abort reason, nothing is sent, and no request state remains.

I traced the cleanup and race behavior: for a pre-aborted signal the abort listener never fires (addEventListener on an already-aborted signal is a no-op), closeById removes it and the state, and only transmitRequest's finally cancels the body, so there is no double cleanup. The check still sits before body encoding, so the stated "no change to the success path" holds.

I also confirmed the tests are discriminating: with base packages/peer/src/client.ts (28db1dd) restored, both new cases fail with expected "vi.fn()" to be called once, but got 0 times. Full peer client suite (55 tests), tsc -b, and eslint on both files are clean.

  ^{｜ View workflow run ｜ Using DeepSeek Flash (default — pick a model for stronger reviews) ｜ 𝕏}