[dinwwwh]

Summary

When a ClientPeer request was aborted while its request message was still being sent, the cancel message could reach the server first. For example, the README transport port.postMessage(await encodePeerMessage(m)) awaits blob.arrayBuffer() for File/FormData bodies. ServerPeer ignores a cancel for an id it has not seen, so the handler then ran with signal.aborted === false, and a streaming response kept going until the peer closed.

Changes

• ClientPeer tracks requestSent, which is set once send(request) resolves.
• abortById sends the cancel only if the request message has been sent. Otherwise transmitRequest checks request.signal?.aborted after the request send and awaits the cancel there, so it always follows the request.
• A request aborted before its message is sent (for example while its body is still being encoded) no longer sends a cancel at all.

Trade-off

On transports whose send only resolves after the server has handled the request, the cancel is no longer sent while that handling runs.

Tests

• New integration test: aborting while file.arrayBuffer() is being read during encoding still aborts the server handler.
• New unit tests: the cancel is sent after the in-flight request message, and no cancel is sent when the request message fails to send.
• Two existing tests changed from expecting only a cancel message to expecting no messages, and one now waits for the cancel instead of asserting it immediately.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TSY5GvoAft9apocjwoSQrk

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

@standard-server/core

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

@standard-server/fastify

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

@standard-server/fetch

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

@standard-server/node

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

@standard-server/peer

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

@standard-server/shared

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

commit: caa86c4

[codspeed]

Merging this PR will not alter performance

✅ 26 untouched benchmarks
⏩ 108 skipped benchmarks¹

---

_{Comparing claude/blissful-fermi-ftb4ay (caa86c4) with main (f414f41)}

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 — verified the client-side cancel ordering fix end to end and traced the abort racing paths; the full suite (1244 tests), eslint, and tsc -b pass.

• Defer cancel until the request message is sent — ClientPeerRequestStateInternal.requestSent gates abortById's cancel send (client.ts:279), with transmitRequest emitting the held-back cancel once the in-flight request send resolves (client.ts:99-105).
• No cancel when the request was never sent — abort during atomic-body encode now sends nothing (previously sent a cancel that the server dropped), and a rejected request send intentionally sends no cancel.
• Tests — new unit helper/tests for abort during an in-flight send (cancel after delivery / none on send failure), plus an integration test aborting mid-encode that only passes with the corrected ordering; existing expectations updated accordingly.

The reasoning is sound: the early set of requestSent and the post-send check share one synchronous block, so no double-cancel window exists, and the server's closeById already no-ops for unknown ids, which is exactly why the old overtaking cancel was lost. I traced the stream-transmit abort path and the peer-close path as unaffected.

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