[robobun]

Repro

A peer that stops reading, then sends Close(1000), then holds the TCP connection open:

import net from "node:net"; import crypto from "node:crypto";
const G = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11";
const srv = net.createServer(s => {
  let h = ""; s.on("data", c => { h += c; const i = h.indexOf("\r\n\r\n"); if (i < 0) return;
    const k = /sec-websocket-key:\s*(\S+)/i.exec(h)[1];
    s.write("HTTP/1.1 101 Switching Protocols\r\nUpgrade: websocket\r\nConnection: Upgrade\r\nSec-WebSocket-Accept: "
      + crypto.createHash("sha1").update(k + G).digest("base64") + "\r\n\r\n");
    s.pause();
    setTimeout(() => { const p = Buffer.alloc(5); p.writeUInt16BE(1000, 0); p.write("bye", 2);
      s.write(Buffer.concat([Buffer.from([0x88, p.length]), p])); }, 500);
  });
});
srv.listen(0, "127.0.0.1", () => {
  const ws = new WebSocket("ws://127.0.0.1:" + srv.address().port);
  ws.onopen = () => { for (let i = 0; i < 256; i++) ws.send("x".repeat(65536)); };
  ws.onclose = e => console.log("close event", e.code);
  setTimeout(() => { console.log("readyState @3s =", ws.readyState); process.exit(0); }, 3000);
});

Before: readyState @3s = 1 (OPEN), no close event, send() at any point keeps queuing into native memory.
Node / undici: readyState @3s = 2 (CLOSING).

Cause

recv_close → send_close_with_body enqueues the echo Close frame behind the user's queued data. When send_buffer is non-empty it parks the JS dispatch in close_dispatch_pending, to be fired by drain_send_buffer_and_finish_close on a later writable event. Nothing notified the C++ WebCore::WebSocket that the closing handshake had started, so m_state stayed OPEN: readyState reported 1 and send() kept calling into the native write path.

RFC 6455 §7.1.3: the closing handshake is started (connection is in the CLOSING state) upon sending or receiving a Close control frame.

Fix

Add an extern "C" WebSocket__didStartClosingHandshake hook and call it from the deferred branch of send_close_with_body, so m_state flips to CLOSING at the moment the close dispatch is parked. The close event itself still fires once the buffer drains or the socket dies (unchanged); only the readyState transition and the send() gate move to Close-frame receipt. For a user-initiated ws.close() under backpressure m_state is already CLOSING, so the call is a no-op there.

WebSocket::terminate() is also changed to gate on CLOSED only (previously CLOSING || CLOSED). With m_state now flipping to CLOSING while the native send queue is still resident against a non-reading peer, the old gate made terminate() a silent no-op in exactly the scenario where force-closing is needed. npm ws's terminate() calls _socket.destroy() for every state except CLOSED; this now matches.

Verification

test/js/web/websocket/websocket-close-backpressure.test.ts:

• raw net.Server completes the handshake, pauses reading, client floods 16 MB, server writes Close(1000), then asserts readyState === CLOSING and that the deferred close event carries {code: 1000, reason: "bye"} once the TCP is torn down. Fails on current main with readyState === 1.
• a second case reaches CLOSING the same way and asserts ws.terminate() fires the close event (code 1006) without the server touching the TCP connection.

---

[review] gate passed · iteration 1 · 4 files touched

fails on main (without fix)

ASAN without fix: 2 FAILED
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/mechgate.xml" test/js/web/websocket/websocket-close-backpressure.test.ts
bun test v1.4.0 (5e7f0550b)

test/js/web/websocket/websocket-close-backpressure.test.ts:
90 |   // transition. Without the fix this stays OPEN for the entire window.
91 |   const deadline = Date.now() + 2000;
92 |   while (ws.readyState === WebSocket.OPEN && Date.now() < deadline) {
93 |     await new Promise<void>(resolve => setImmediate(resolve));
94 |   }
95 |   expect(ws.readyState).toBe(WebSocket.CLOSING);
                             ^
error: expect(received).toBe(expected)

Expected: 2
Received: 1

      at backpressuredCloseSetup (/workspace/bun/test/js/web/websocket/websocket-close-backpressure.test.ts:95:25)
      at async <anonymous> (/workspace/bun/test/js/web/websocket/websocket-close-backpressure.test.ts:101:38)
(fail) readyState becomes CLOSING when a Close frame arrives while the send queue is backpressured [2882.86ms]
90 |   // transition. Without the fix this stays OPEN for the entire window.
91 |   const deadline = Date.now() + 2000;
92 |   while (ws.readySta
... (truncated)

release without fix: all passed
bun test v1.4.0-canary.1 (bd6a87284)

test/js/web/websocket/websocket-close-backpressure.test.ts:
(pass) readyState becomes CLOSING when a Close frame arrives while the send queue is backpressured [47.69ms]
(pass) terminate() during CLOSING force-closes while the send queue is still backpressured [22.78ms]

 2 pass
 0 fail
 9 expect() calls
Ran 2 tests across 1 file. [299.00ms]
__F:0:S:0

passes on PR (with fix)

ASAN with fix: all passed
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/mechgate.xml" test/js/web/websocket/websocket-close-backpressure.test.ts
bun test v1.4.0 (5e7f0550b)

test/js/web/websocket/websocket-close-backpressure.test.ts:
(pass) readyState becomes CLOSING when a Close frame arrives while the send queue is backpressured [587.39ms]
(pass) terminate() during CLOSING force-closes while the send queue is still backpressured [244.05ms]

 2 pass
 0 fail
 9 expect() calls
Ran 2 tests across 1 file. [3.24s]
__F:0:S:0

release with fix: all passed
$ bun scripts/build.ts --profile=release
[configured] bun-profile → bun (stripped)
  target       linux-x64-gnu
  build type   Release
  build dir    ./build/release
  revision     5e7f0550b9
  features     baseline

22 deps, 108 codegen, 1171 objects in 724ms

ninja: Entering directory `/workspace/bun/build/release'
[1/22] gen cpp.rs (cppbind)
[2/22] gen generated_host_exports.rs
generated_host_exports.rs: 94 exports (host=3, lazy=10, generic=81, rust=0); 239 extern-C blocks audited
[2/22] cargo bun_bin → libbun_rust.a (--target x86_64-unknown-linux-gnu)

  nightly-2026-07-20-x86_64-unknown-linux-gnu unchanged - rustc 1.99.0-nightly (9f36de775 2026-07-19)

�[1m�[92m   Compiling�[0m bun_core v0.0.0 (/workspace/bun/src/bun_core)
�[1m�[92m   Compiling�[0m bun_errno v0.0.0 (/workspace/bun/src/errno)
�[1m�[92m   Compiling�[0m bun_ptr v0.0.0 (/workspace/bun/src/ptr)
�[1m�[92m   Compiling�[0m bun_boringssl_sys v0.0.0 (/workspace/bun/src/boringssl_sys)
�[1m�[92m   Compiling�[0m bun_safety v0.0.0 (/workspace/bun/src/safety)
�[1m�[92m   Compiling�[0m bun_zlib_sys v0.0.0 (/workspace/bun/src/zlib_sys)
�[1m�[92m   Compiling�[0m bun_cares_sys v0.0.0 (/workspace/bun/src/cares
... (truncated)

diff hotspot

src/http_jsc/websocket_client.rs                   |   4 +
 src/http_jsc/websocket_client/CppWebSocket.rs      |   6 +
 src/jsc/bindings/webcore/WebSocket.cpp             |   6 +-
 .../websocket/websocket-close-backpressure.test.ts | 131 +++++++++++++++++++++
 4 files changed, 146 insertions(+), 1 deletion(-)

gate history · 5 passed · 0 rejected · iteration 1

evidence per changed file

file                                                      reads  edits  tests
src/http_jsc/websocket_client.rs                              6      2      0
src/http_jsc/websocket_client/CppWebSocket.rs                 3      5      0
src/jsc/bindings/webcore/WebSocket.cpp                       10      6      0
…t/js/web/websocket/websocket-close-backpressure.test.ts      2      8      0

[coderabbitai]

Walkthrough

WebSocket close handling now notifies WebCore when a partially written close frame begins the closing handshake. Rust and C++ callback plumbing was added, along with a regression test covering close-state transitions under send backpressure.

Changes

WebSocket close handshake

Layer / File(s)	Summary
Native handshake callback bridge src/http_jsc/websocket_client/CppWebSocket.rs, src/jsc/bindings/webcore/WebSocket.cpp	Adds Rust and C++ bindings that forward did_start_closing_handshake() to WebCore.
Buffered close integration and regression coverage src/http_jsc/websocket_client.rs, test/js/web/websocket/websocket-close-backpressure.test.ts	Notifies the native WebSocket when a queued close frame is still draining and tests closing-state and buffering behavior under backpressure.

Possibly related PRs

• oven-sh/bun#35872: Refactors deferred WebSocket Close behavior in the same close-dispatch flow.

Suggested reviewers: jarred-sumner

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly summarizes the main fix: readyState becomes CLOSING when a Close frame arrives under backpressure.
Description check	✅ Passed	The description covers the change, cause, and verification, though it uses custom headings instead of the template's exact section names.

---

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

Status: diff is green; CI failures are unrelated flakes.

Fail-before (USE_SYSTEM_BUN=1 bun test test/js/web/websocket/websocket-close-backpressure.test.ts):

error: expect(received).toBe(expected)
Expected: 2
Received: 1

Pass-after (bun bd test test/js/web/websocket/websocket-close-backpressure.test.ts):

(pass) readyState becomes CLOSING when a Close frame arrives while the send queue is backpressured
(pass) terminate() during CLOSING force-closes while the send queue is still backpressured

Also changed WebSocket::terminate() to force-close during CLOSING (npm ws parity); the new CLOSING transition would otherwise have made terminate() a no-op against a stalled peer.

CI: builds 85305 and 85378 both show only [flaky]-classified failures in unrelated tests (terminal, fetch-leak, spawn, shell-leak, grpc, fs-read-stream, etc.), none touching WebSocket code and websocket-close-backpressure.test.ts passing on every lane. Ready for maintainer merge.

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@test/js/web/websocket/websocket-close-backpressure.test.ts`:
- Around line 72-77: Replace the setTimeout-based delay inside the readyState
polling loop with a setImmediate event-loop yield. Keep the existing deadline
and WebSocket.OPEN condition unchanged so the test remains bounded while
awaiting the CLOSING transition without load-sensitive timer polling.
- Around line 62-67: Add an assertion in the websocket backpressure setup around
the initial ws.send loop to verify that sends actually populate the userspace
queue before checking ws.readyState. Use the existing websocket/socket
backpressure state exposed by the test, and keep the OPEN-state assertion so the
test proves the deferred-close path is exercised rather than merely relying on
the send volume.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: b2d79d95-b0a1-4a9b-bca3-88ca4db902d4

📥 Commits

Reviewing files that changed from the base of the PR and between 4eb6f99 and dc3811d.

📒 Files selected for processing (4)

• src/http_jsc/websocket_client.rs
• src/http_jsc/websocket_client/CppWebSocket.rs
• src/jsc/bindings/webcore/WebSocket.cpp
• test/js/web/websocket/websocket-close-backpressure.test.ts

[claude]

Additional findings (outside current diff — PR may have been updated during review):

• 🟡 src/jsc/bindings/webcore/WebSocket.cpp:1055-1060 — nit: this 5-line comment mixes the durable rationale (npm-ws parity for terminate()) with bug-history narration ("a server-initiated Close under send backpressure flips m_state to CLOSING while the native send_buffer is still resident, and terminate() is the only JS-level escape hatch to free it"), which per REVIEW.md belongs in the PR description, not source. The comment-cop bot already flagged this line (the only unresolved thread on the PR); the identical flag on websocket_client.rs earlier in this PR was resolved in c9ef4a0 by trimming to one line — same fix applies here, e.g. // Force-close during CLOSING too (matches npm ws, whose terminate() calls _socket.destroy()).

  Extended reasoning...

  What this is

  Commit 44a7c2a changed WebSocket::terminate()'s gate from if (m_state == CLOSING || m_state == CLOSED) to if (m_state == CLOSED) and added a 5-line comment above it (WebSocket.cpp:1055-1059):

  // terminate() must still force-close during CLOSING (matching npm ws,
  // which calls _socket.destroy() for any state except CLOSED): a
  // server-initiated Close under send backpressure flips m_state to
  // CLOSING while the native send_buffer is still resident, and
  // terminate() is the only JS-level escape hatch to free it.
  if (m_state == CLOSED)

  The repo's comment-cop bot fired on this at 2026-07-27T16:26:49Z with the CLAUDE.md rule #13 text ("If you need a paragraph-long comment to justify why the workaround is OK, the code is wrong — fix the code"), and that inline comment is the only unresolved review thread on the PR — every other <inline-comment> in the timeline carries resolved="true".

  Why the comment violates REVIEW.md

  REVIEW.md's comment rule: "Comments carry only durable non-obvious content: invariants, ownership/lifetime contracts, SAFETY justifications, deliberate deviations from upstream. No narrating what the code does, no bug history — that belongs in the PR description."

  The comment splits into two clauses:

  1. Durable / deliberate-deviation content (keep): "terminate() must still force-close during CLOSING (matching npm ws, which calls _socket.destroy() for any state except CLOSED)" — this explains why the gate is == CLOSED rather than the WebCore-original CLOSING || CLOSED, and cites the compat reference. A future reader who sees this diverging from browser terminate() semantics needs this.
  2. Bug-history narration (move to PR description): "a server-initiated Close under send backpressure flips m_state to CLOSING while the native send_buffer is still resident, and terminate() is the only JS-level escape hatch to free it" — this is the specific scenario that motivated the change in this PR. It is already stated in the PR description's "Cause" section and in the earlier review comment that prompted 44a7c2a. Per REVIEW.md, that belongs in the PR description, not source.

  The code itself is not a workaround — relaxing the CLOSING gate is the correct fix (npm ws compat, and required for the adversarial scenario this PR hardens). So the resolution is to trim the comment, not change the code.

  In-PR precedent

  The identical bot flag fired earlier in this PR on src/http_jsc/websocket_client.rs (2026-07-27T15:37:25Z), and the author resolved it in commit c9ef4a0 ("trim comment in send_close_with_body deferred branch") by reducing to a single line: // readyState still flips to CLOSING now (RFC 6455 §7.1.3). The author's own reply was "Trimmed to a single line in c9ef4a0." The same fix applies here.

  On the "duplicate of existing PR comment" objection

  One verifier noted the bot has already surfaced this. That's true, and the author has a track record of responding to it. But the bot's message is the generic rule-#13 quote — it doesn't say whether the code is wrong (revert the gate change?) or the comment is wrong (trim it), nor which portion of the comment is the bug-history part vs. the durable part. This finding resolves that ambiguity: the code is correct, the second sentence of the comment is bug-history, and the concrete one-line replacement preserves the deliberate-deviation content REVIEW.md says to keep. Given it is the sole unresolved thread on the PR, surfacing the actionable remedy alongside it is useful, not redundant.

  Step-by-step

  1. Open WebSocket.cpp at terminate() (line 1052). The comment at 1055-1059 spans 5 lines above if (m_state == CLOSED).
  2. First clause (lines 1055-1056, up to the colon): npm-ws parity rationale → "deliberate deviation from upstream" per REVIEW.md → durable, keep.
  3. Second clause (lines 1056-1059, after the colon): describes the send-backpressure scenario from this PR's motivating repro → "bug history" per REVIEW.md → belongs in PR description.
  4. PR timeline: comment-cop inline on WebSocket.cpp:1059 has no resolved attribute; every other inline comment does. It is the only open thread.
  5. Precedent: commit c9ef4a0 resolved the identical bot flag on websocket_client.rs by trimming to one line. Applying the same here yields:

     // Force-close during CLOSING too (matches npm ws, whose terminate() calls _socket.destroy()).
     if (m_state == CLOSED)

  Impact & severity

  Zero runtime impact — comment-only. This is a repo-convention / CLAUDE.md #13 style violation flagged by automated tooling. Severity: nit. Not blocking; worth fixing before merge to clear the last open review thread.

[claude]

No issues found — all four rounds of prior feedback were addressed and the fail-before/pass-after evidence covers both debug+ASAN and release. Deferring only because the terminate() gate change (now force-closes during CLOSING, matching npm ws) is a user-visible behavior change on a public Web API that a maintainer should sign off on.

What was reviewed:

• Traced send_close_with_body → did_start_closing_handshake for both server-initiated (recv_close) and user-initiated (ws.close()) entry — the C++ call is idempotent when m_state is already CLOSING and never dispatches JS.
• Checked terminate() after user close() under backpressure and after a second terminate(): m_connectedWebSocketKind = None / m_state = CLOSED make repeats safe; cancel() → clear_data() takes close_dispatch_pending before handle_close reads it, so the abrupt-close path fires 1006 as tested.
• Test hermeticity: cleanup registered before awaits, failure events reject the setup promises, bounded setImmediate poll.

Extended reasoning...

Overview

The PR adds a WebSocket__didStartClosingHandshake FFI hook so the Rust client can flip C++ m_state to CLOSING the moment a server Close frame is received while the outbound queue is backpressured (RFC 6455 §7.1.3), instead of deferring until the queue drains. It also relaxes the WebSocket::terminate() gate from CLOSING || CLOSED to CLOSED only, so users retain a force-close escape hatch against a stalled peer during CLOSING (npm ws parity). ~15 lines of production code across websocket_client.rs, CppWebSocket.rs, and WebSocket.cpp, plus a 131-line test file with two cases.

Security risks

None identified. The new hook only mutates m_state and calls updateHasPendingActivity(); no JS dispatch, no allocation, no user-controlled input reaches new parsing. The terminate() change widens when a user can force-close their own socket — no adversarial surface.

Level of scrutiny

Medium-high. This is a protocol state-machine change on a public Web API (WebSocket) crossing the Rust/C++ FFI boundary, with a user-visible behavior change to terminate(). Not a mechanical/config change. That said, the diff is small, the mechanism is a single well-placed hook + a one-line gate relaxation, and it has been through four rounds of review with each concern addressed and re-verified (fail-before/pass-after on both ASAN-debug and release).

Other factors

I raised the terminate() issue myself in a prior pass and suggested exactly this fix; the author applied it correctly with a covering test. All CodeRabbit and comment-cop feedback is resolved. The test uses a local net.Server, port 0, bounded polling, and registers cleanup before assertions. I traced re-entry safety (didStartClosingHandshake never enters JS; ref guards held at both call sites) and the terminate()-after-close() and double-terminate() paths — all reduce to idempotent state writes. I'm deferring rather than approving solely because the terminate() semantics change on a public API is the kind of decision a maintainer should explicitly OK, per the "do NOT approve when there are design decisions a human should weigh in on" guideline.

[claude]

All prior review feedback has been addressed and no new issues were found. I'm deferring rather than approving because the terminate() gate change (now force-closes during CLOSING, matching npm ws) is a user-visible behavior change to the WebSocket state machine that a maintainer should sign off on.

What was reviewed:

• did_start_closing_handshake() is a pure m_state write with no JS dispatch; safe to call from the recv path without event-loop enter/exit and without re-entering Rust.
• terminate() after a user-initiated ws.close() under backpressure now reaches cancel(); traced ref-count balance through ScopedRef guard → clear_data → handle_close → dispatch_abrupt_close and found no double-free or leak.
• Repeated terminate() is safe: second call sees m_connectedWebSocketKind == None and falls through the switch.
• Test: cleanup registered before awaits, failure paths reject, close-event assertions prove the deferred-dispatch branch was taken.

Extended reasoning...

Overview

This PR fixes an RFC 6455 §7.1.3 compliance gap: when a server Close frame arrives while the client's outbound queue is backpressured, readyState now transitions to CLOSING immediately (matching Node/undici) instead of staying OPEN until the queue drains. The change is small — a new WebSocket__didStartClosingHandshake FFI hook (4 lines Rust call site, 6 lines Rust wrapper, 4 lines C++ extern), plus a one-line change to WebSocket::terminate()'s gate (CLOSING || CLOSED → CLOSED only), plus a 131-line test.

Security risks

None identified. No parsing changes, no new allocation paths, no user-controlled input reaching new code. The new FFI hook only mutates m_state and m_hasPendingActivity.

Level of scrutiny

Medium-high. WebSocket close lifecycle is subtle (ref-counted native client, deferred dispatch, tunnel mode, synchronous re-entrancy from uSockets close callbacks) and this is production network code. I traced the ref-count balance for the new terminate()-during-CLOSING path: cancel()'s ScopedRef guard keeps the allocation live across clear_data() → tcp.close() → synchronous handle_close → dispatch_abrupt_close (drops the C++ ref) → socket deref, and the guard's own drop is the final release. No imbalance found. The didStartClosingHandshake() call from send_close_with_body's deferred branch is safe — it does not dispatch JS and cannot re-enter Rust; for a user-initiated ws.close() under backpressure it's a no-op (m_state already CLOSING).

Other factors

This PR has been through three prior review rounds (mine and CodeRabbit's), all findings addressed: the vacuous toBeGreaterThanOrEqual assertion, the CppWebSocket impl-block placement, the setTimeout poll, the terminate() no-op regression I flagged, and the test's failure-path wiring / cleanup ordering. The terminate() gate change is the piece that gives me pause on auto-approval — it's a deliberate npm-ws-parity behavior change (force-close during CLOSING instead of no-op) that affects any existing user code calling terminate() after close(). It's the right change, but it's user-facing API semantics and belongs to a maintainer's judgment call rather than a bot approval.

[Jarred-Sumner]

@robobun fix conflicts

[robobun]

Conflicts resolved in bd6a872 (both sides added an FFI import in CppWebSocket.rs; kept both). Rebuilt and both tests pass locally.

[claude]

No issues found this pass — all four rounds of prior feedback (mine, CodeRabbit's, comment-cop's) are addressed and the merge conflict is resolved. Deferring to a maintainer because the terminate() gate change is a user-visible behavior change to a public API (previously a no-op during CLOSING, now force-closes), and while it's the right fix and matches npm ws, it's worth a human sign-off.

What was reviewed:

• Traced did_start_closing_handshake from all three send_close_with_body callers (server Close, user close(), bodyless Close) — the C++ side only mutates m_state + updateHasPendingActivity, no JS dispatch or re-entry.
• Traced terminate() during CLOSING for both user-initiated-close-then-terminate and server-Close-then-terminate: cancel → clear_data drops close_dispatch_pending, handle_close → dispatch_abrupt_close fires 1006, refcounts balance via the ScopedRef guard, and a second terminate() falls through the None switch arm.
• Confirmed the test's setup wires failure paths to reject and registers cleanup before the awaits (per the last round of feedback).

Extended reasoning...

Overview

Four files: a 4-line addition in src/http_jsc/websocket_client.rs (call did_start_closing_handshake() in the deferred-close branch of send_close_with_body), a new FFI import + 4-line wrapper in CppWebSocket.rs, a one-line gate change in WebSocket::terminate() plus a new 3-line extern "C" stub in WebSocket.cpp, and a new 131-line test file with two cases.

The functional change is: when a server Close frame arrives while the client's send queue is backpressured, flip the C++ m_state to CLOSING immediately (RFC 6455 §7.1.3) rather than leaving it OPEN until the queue drains. The terminate() gate change (CLOSING || CLOSED → CLOSED only) is the same-class fix I flagged in a prior round: without it, the new CLOSING transition would have made terminate() a silent no-op in exactly the adversarial scenario being hardened.

Security risks

None identified. The change gates more on the receipt of a peer Close frame (stops send() from queuing native memory), which is strictly a hardening. didStartClosingHandshake does no JS dispatch and cannot re-enter. The terminate() change makes force-close more available, not less — a user who could call terminate() in OPEN could always force-close; now they can also do so in CLOSING.

Level of scrutiny

Medium-high. This is WebSocket client protocol/state-machine code with an FFI boundary and refcount management, and terminate() is a documented public API whose semantics are changing (no-op → force-close during CLOSING). The change itself is small and I've traced the refcount and re-entry paths across the Rust/C++ boundary for the new callers, but a public-API behavior change on a networking primitive deserves a maintainer's confirmation that npm-ws parity is the intended contract here.

Other factors

This PR has been through four rounds of review feedback (all resolved): the vacuous toBeGreaterThanOrEqual assertion, the impl-block placement of did_start_closing_handshake, the terminate() gate regression, and the test's failure-path wiring/cleanup ordering. CodeRabbit's bufferedAmount > 0 precondition suggestion was correctly declined (Bun doesn't reflect the native queue in bufferedAmount while OPEN). Jarred requested a conflict fix, which was done and the tests re-run locally. The bug-hunting system found nothing new on the current revision. Given the review history and Jarred's existing engagement, this is close to approvable — I'm deferring only on the public-API-semantics change.

[robobun]

^{Updated 1:25 PM PT - Jul 29th, 2026}

✅ @robobun, your commit 5e7f0550b9530450b950529fab2fe836d8a2735c passed in Build #85378! 🎉

---

🧪   To try this PR locally:

bunx bun-pr 36112

That installs a local version of the PR into your bun-36112 executable, so you can run:

bun-36112 --bun

[Jarred-Sumner]

This is Claude, working with Jarred on consolidating the open WebSocket PRs.

Superseded by #45223 (taken; both hunks live on in the new close state machine).

Both halves are real. After the server's Close, with our sends backed up, readyState stayed OPEN and send(1000) moved bufferedAmount from 12458315 to 12459323: data queued behind our own Close echo, against RFC 6455 5.5.1.

And close() under backpressure followed by terminate() did nothing, so the process never ended. That one needs no Close from the peer: the title undersells the PR.

Three additions: didStartClosingHandshake() is called for every Close received, not only in the deferred branch; terminate() reports a code that was already received, as npm ws does; and the close timeout is armed when the Close frame is queued, so the stalled state ends without terminate() too.

Tests: websocket-close-code.test.ts, "WebSocket closing handshake > with a server that stopped reading" (3 cases, with the bufferedAmount > 0 precondition CodeRabbit asked for), instead of a new file.