[robobun]

Fixes #31760

#40566 implemented the live client bufferedAmount. This PR is now the follow-up that keeps the value correct through close.

Problem

• After WebSocket client: pause()/resume(), working bufferedAmount, and a ServerWebSocket drain stall fix #40566, bufferedAmount resets to 0 on every close path that drops the native client: terminate(), a protocol-error abort, a server-initiated close, and a peer TCP close. The WHATWG spec says the value "does not reset to zero once the connection closes". didClose (src/jsc/bindings/webcore/WebSocket.cpp:1500) receives no snapshot and didFailWithErrorCode takes no buffered argument, so the queued backlog is lost with the send buffer.
• The Blob overloads of send()/ping()/pong() and the no-argument ping()/pong() return early after close without adding to m_bufferedAmountAfterClose, unlike the String and ArrayBuffer overloads.

Fix

• Every Rust close path (fail, handle_close, send_close_with_body, finish_pending_close) snapshots buffered_amount() before clear_data() frees the buffer and passes it through WebSocket__didClose/WebSocket__didAbruptClose. didClose() keeps the largest of the current value and the snapshot, so wasClean stays true on a clean close. terminate() snapshots eagerly in C++ before cancelConnectedClient() detaches the client.
• The Blob overloads accumulate clampToUnsigned(size) + getFramingOverhead(size) after close. The no-argument ping()/pong() add their 6 framing bytes, matching ping("").
• Verified: test/js/web/websocket/websocket-buffered-amount.test.ts gains 9 retention tests, 5 of which fail on main. The 7 live-tracking tests from WebSocket client: pause()/resume(), working bufferedAmount, and a ServerWebSocket drain stall fix #40566 still pass, as does the rest of test/js/web/websocket/.

Background

• The native client frees its send buffer in clear_data() during teardown, so the backlog must be read before that point and carried across the FFI callback.
• m_bufferedAmount holds the final snapshot once the client is detached. m_bufferedAmountAfterClose counts payloads handed to send()/ping()/pong() after close, which are never written.

Notes

This PR originally implemented the whole client bufferedAmount (live getter plus retention). #40566 landed an independent live implementation, so this branch was rebased down to the retention and post-close accounting delta on top of it. The FFI getter, the tunnel accessor, and the headers.h declarations now come from main. The close-path snapshot threading, the didClose/didFailWithErrorCode max-keeping, the terminate() eager snapshot, and the overload accounting are this PR's remaining content, unchanged from the reviewed versions. Earlier review rounds (memory-safety, aliasing, clamping) all applied to these paths and their findings are preserved.

Known gap (tunnel only, documented in-source): a fatal SSL error inside the tunnel's write_data fires fail() before the send buffer is restored, so that snapshot reads 0. No worse than the pre-feature behavior.

---

[review] gate passed · iteration 28 · 6 files touched

fails on main (without fix)

ASAN without fix: 5 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-buffered-amount.test.ts
bun test v1.4.1 (adc354d99)

test/js/web/websocket/websocket-buffered-amount.test.ts:
(pass) WebSocket.bufferedAmount (ws) > counts bytes the peer has not accepted and drains to 0 [955.91ms]
(pass) WebSocket.bufferedAmount (wss) > counts bytes the peer has not accepted and drains to 0 [1084.52ms]
(pass) WebSocket.bufferedAmount (wss via http:// proxy) > counts bytes the peer has not accepted and drains to 0 [748.03ms]
(pass) WebSocket.bufferedAmount (wss via https:// proxy) > counts bytes the peer has not accepted and drains to 0 [705.60ms]
(pass) WebSocket.bufferedAmount (ws via https:// proxy) > counts bytes the peer has not accepted and drains to 0 [682.33ms]
(pass) WebSocket.bufferedAmount > is 0 once a small message has been written [56.94ms]
(pass) WebSocket.bufferedAmount > ws package reports the same number [802.02ms]
(pass) WebSocket.bufferedAmount (client) > reflects the backlog queued to a peer that stopped reading [2168.76ms]
(pass) WebSocket.bufferedAmount (client) > 
... (truncated)

release without fix: 15 FAILED
bun test v1.4.1-canary.1 (adc354d99)

test/js/web/websocket/websocket-buffered-amount.test.ts:
107 | 
108 |         for (let i = 0; i < TOTAL; i++) ws.send(CHUNK);
109 | 
110 |         // The kernel and any proxy absorbed some; the rest is ours to report.
111 |         const queued = ws.bufferedAmount;
112 |         expect(queued).toBeGreaterThan(TOTAL_BYTES / 2);
                             ^
error: expect(received).toBeGreaterThan(expected)

Expected: > 33554432
Received: 0

      at <anonymous> (/workspace/bun/test/js/web/websocket/websocket-buffered-amount.test.ts:112:24)
(fail) WebSocket.bufferedAmount (ws) > counts bytes the peer has not accepted and drains to 0 [66.78ms]
107 | 
108 |         for (let i = 0; i < TOTAL; i++) ws.send(CHUNK);
109 | 
110 |         // The kernel and any proxy absorbed some; the rest is ours to report.
111 |         const queued = ws.bufferedAmount;
112 |         expect(queued).toBeGreaterThan(TOTAL_BYTES / 2);
                             ^
error: expect(received).toBeGreaterThan(expected)

Expected: > 33554432
Received: 0

      at <anonymous> (/workspace/bun/test/js/web/websocket/websocket-buffered-amount.test.ts:112:24)
(fail) 
... (truncated)

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-buffered-amount.test.ts
bun test v1.4.1 (adc354d99)

test/js/web/websocket/websocket-buffered-amount.test.ts:
(pass) WebSocket.bufferedAmount (ws) > counts bytes the peer has not accepted and drains to 0 [965.77ms]
(pass) WebSocket.bufferedAmount (wss) > counts bytes the peer has not accepted and drains to 0 [1087.37ms]
(pass) WebSocket.bufferedAmount (wss via http:// proxy) > counts bytes the peer has not accepted and drains to 0 [749.17ms]
(pass) WebSocket.bufferedAmount (wss via https:// proxy) > counts bytes the peer has not accepted and drains to 0 [835.84ms]
(pass) WebSocket.bufferedAmount (ws via https:// proxy) > counts bytes the peer has not accepted and drains to 0 [635.40ms]
(pass) WebSocket.bufferedAmount > is 0 once a small message has been written [52.60ms]
(pass) WebSocket.bufferedAmount > ws package reports the same number [870.11ms]
(pass) WebSocket.bufferedAmount (client) > reflects the backlog queued to a peer that stopped reading [2223.95ms]
(pass) WebSocket.bufferedAmount (client) > 
... (truncated)

release with fix: all passed
$ bun scripts/build.ts --profile=release
[configured] bun-profile → bun (stripped) in 645ms (unchanged)
ninja: Entering directory `/workspace/bun/build/release'
[1/13] cxx obj/src/jsc/bindings/ZigGlobalObject.cpp.o
[2/13] cxx obj/unified/UnifiedSource-src_runtime_webview-0.cpp.o
[3/13] cxx obj/unified/UnifiedSource-src_jsc_bindings_webcore-3.cpp.o
[4/13] cxx obj/unified/UnifiedSource-src_jsc_bindings-4.cpp.o
[5/13] cxx obj/unified/UnifiedSource-src_jsc_bindings-1.cpp.o
[6/13] cxx obj/unified/UnifiedSource-src_jsc_bindings_webcore-2.cpp.o
[7/13] gen generated_host_exports.rs
generated_host_exports.rs: 122 exports (host=5, lazy=10, generic=107, rust=0); 243 extern-C blocks audited
[8/13] gen cpp.rs (cppbind)
[8/13] cargo bun_runtime → libbun_runtime.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_bundler v0.0.0 (/workspace/bun/src/bundler)
�[1m�[92m   Compiling�[0m bun_standalone_graph v0.0.0 (/workspace/bun/src/standalone_graph)
�[1m�[92m   Compiling�[0m bun_transpiler v0.0.0 (/workspace/bun/src/transpiler)
�[1m�[92m   Compiling�[0m bun_bunf
... (truncated)

diff hotspot

src/http_jsc/websocket_client.rs                   |  73 +++-
 src/http_jsc/websocket_client/CppWebSocket.rs      |  29 +-
 .../websocket_client/WebSocketUpgradeClient.rs     |   3 +-
 src/jsc/bindings/webcore/WebSocket.cpp             | 100 +++--
 src/jsc/bindings/webcore/WebSocket.h               |   7 +-
 .../websocket/websocket-buffered-amount.test.ts    | 408 ++++++++++++++++++++-
 6 files changed, 569 insertions(+), 51 deletions(-)

gate history · 7 passed · 0 rejected · iteration 28

evidence per changed file

file                                                     reads  edits  tests
src/http_jsc/websocket_client.rs                            39     52     67
src/http_jsc/websocket_client/CppWebSocket.rs                9     13     65
src/http_jsc/websocket_client/WebSocketUpgradeClient.rs      3      3     65
src/jsc/bindings/webcore/WebSocket.cpp                      26     32     67
src/jsc/bindings/webcore/WebSocket.h                         4      5     67
test/js/web/websocket/websocket-buffered-amount.test.ts     27     32     64

root cause · written by the author bot

The client WebSocket's bufferedAmount lost any queued send backlog the moment the connection was torn down, because the native close and failure paths discarded the buffer before the getter could observe it, leaving the value stuck at zero after close, terminate, or an abrupt disconnect. The fix snapshots the native send backlog before teardown, threads that count through the close and error callbacks into the C++ layer, and retains the larger of the snapshot and any previously recorded amount. It also accounts for data queued after close in the Blob and no-argument send overloads, so buffe…

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

Walkthrough

Adds live client bufferedAmount by summing the Rust send buffer and optional proxy-tunnel backlog, exports C‑ABI getters for TLS/non‑TLS, threads buffered snapshots into C++ close/fail callbacks, updates C++ bufferedAmount logic, and adds client tests exercising backlog and close/abort paths.

Changes

WebSocket client bufferedAmount reporting

Layer / File(s)	Summary
Proxy tunnel buffering measurement src/http_jsc/websocket_client/WebSocketProxyTunnel.rs	WebSocketProxyTunnel exposes buffered_amount() returning the encrypted write_buffer size.
Rust WebSocket buffered-amount, snapshotting, and export src/http_jsc/websocket_client.rs	Adds WebSocket::buffered_amount, snapshots send backlog before teardown, restores send_buffer on send failure, and extends export_websocket_client! to generate Bun__WebSocketClient__getBufferedAmount and TLS variant shims; threads buffered snapshots into dispatch_close/dispatch_abrupt_close.
Rust FFI: C++ callback surface src/http_jsc/websocket_client/CppWebSocket.rs	Update extern declarations and CppWebSocket::did_abrupt_close / did_close wrappers to accept and forward buffered_amount.
Upgrade client abrupt-close callsite src/http_jsc/websocket_client/WebSocketUpgradeClient.rs	Callsite now supplies explicit zero backlog when invoking did_abrupt_close.
C binding declarations src/jsc/bindings/headers.h	Declare Bun__WebSocketClient__getBufferedAmount and Bun__WebSocketClientTLS__getBufferedAmount.
C++ WebCore bufferedAmount integration src/jsc/bindings/webcore/WebSocket.cpp, src/jsc/bindings/webcore/WebSocket.h	Add clamp helper; snapshot native buffered backlog before close()/terminate(); preserve larger buffered amounts across didClose/didFailWithErrorCode; update extern "C" bridges to accept bufferedAmount; compute bufferedAmount() from live native backlog plus post-close accumulation.
Client bufferedAmount tests test/js/web/websocket/websocket-buffered-amount.test.ts	Add nonDrainingServer, protocol frame helpers, and five tests covering bufferedAmount growth, retention across close(), abrupt-close observation, server-initiated graceful close, and abrupt socket-destroy behavior.

• Possibly related PRs:

  • oven-sh/bun#31518: Modifies WebSocket close/teardown paths and native-Rust integration at similar callback sites.
  • oven-sh/bun#30722: Overlaps WebSocket client close-path changes that touch similar teardown code.

• Suggested reviewers:

  • Jarred-Sumner

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The PR fully addresses issue #31760 by implementing client WebSocket.bufferedAmount reporting, making send backpressure observable, providing live buffer queries, and adding comprehensive tests coveri…
Out of Scope Changes check	✅ Passed	All changes are within scope: adding buffered-amount accessors to Rust client, updating C++ callback signatures to thread buffered amounts, adding FFI declarations, and comprehensive test coverage. No…
Title check	✅ Passed	The title clearly and concisely describes the primary change: preserving client WebSocket.bufferedAmount after close.
Description check	✅ Passed	The description explains the problem, implementation, affected close paths, post-close accounting, verification results, known gap, and test evidence. It does not use the template headings exactly, bu…

Full details: Linked Issues check

Explanation

The PR fully addresses issue #31760 by implementing client WebSocket.bufferedAmount reporting, making send backpressure observable, providing live buffer queries, and adding comprehensive tests covering baseline and growth scenarios.

Full details: Out of Scope Changes check

Explanation

All changes are within scope: adding buffered-amount accessors to Rust client, updating C++ callback signatures to thread buffered amounts, adding FFI declarations, and comprehensive test coverage. No unrelated modifications detected.

Full details: Description check

Explanation

The description explains the problem, implementation, affected close paths, post-close accounting, verification results, known gap, and test evidence. It does not use the template headings exactly, but it provides the required information and is sufficiently complete.

---

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

[robobun]

^{Updated 2:36 PM PT - Aug 26th, 2026}

❌ @autofix-ci[bot], your commit 9ac1675 has 2 failures in Build #106367 (All Failures):

• test/cli/run/require-cache.test.ts - code 1: error: Memory leak detected on 🐧 13 x64-asan
• ❌ CPU instruction violation on Windows x64 — 1 check(s) failed

The baseline build contains instructions not available on Nehalem (SSE4.2, no AVX/AVX2/AVX512).

• Static instruction scan

Static scan violations

__std_max_4u  [AVX, AVX2]  (16 insns)
If these are runtime-dispatched behind a CPUID gate: add each symbol to
scripts/verify-baseline-static/allowlist-x64-windows.txt with a comment pointing at the gate.
If there's no gate: this is a real bug — a -march leaked into a subbuild.

---

🧪   To try this PR locally:

bunx bun-pr 31761

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

bun-31761 --bun

[coderabbitai]

Actionable comments posted: 1

🤖 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 `@src/http_jsc/websocket_client.rs`:
- Around line 2096-2111: The current get_buffered_amount implementation reports
framed/encrypted wire bytes by calling send_buffer.readable_length() and
proxy_tunnel.buffered_amount(); instead introduce and use a dedicated plaintext
queued-byte counter (e.g., a field like queued_plain_bytes) that is incremented
in the send() enqueue path and decremented in the write/drain completion path
(and when proxied bytes are handed to the tunnel) and ensure proxy_tunnel
contributions are accounted only as the plaintext bytes handed off, then modify
get_buffered_amount to return this counter instead of the framed/encrypted
buffer lengths (update send(), drain/write completion, and any tunnel-handoff
code paths accordingly).

🪄 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: 5791622e-7ba5-4831-8a71-b8a4748ecdd5

📥 Commits

Reviewing files that changed from the base of the PR and between d2a6506 and 00deb1d.

📒 Files selected for processing (5)

• src/http_jsc/websocket_client.rs
• src/http_jsc/websocket_client/WebSocketProxyTunnel.rs
• src/jsc/bindings/headers.h
• src/jsc/bindings/webcore/WebSocket.cpp
• test/js/web/websocket/websocket-buffered-amount.test.ts

[robobun]

CI is green on the diff — the only red lane is `darwin-14-x64-test-bun`, failing on `test/js/bun/terminal/terminal.test.ts > creates subprocess with terminal attached` (a PTY test that times out at 90s on loaded macOS runners; unrelated to this PR and previously flaked on the same lane in build #60150). The earlier `serve-body-leak` memory-threshold blip on `debian-13-x64-asan` passed on retry — that lane is green.

All WebSocket coverage passes, including `debian-13-x64-asan` (ASAN, where the tunnel-aliasing fix matters most), `darwin-26-aarch64`, and every Linux/Windows lane. The new `websocket-buffered-amount` tests pass on all lanes.

I have already used my one CI re-roll, so I am not pushing another retrigger. This needs a maintainer to re-run the macOS lane / merge past the unrelated PTY flake.

[coderabbitai]

Actionable comments posted: 1

🤖 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 `@src/http_jsc/websocket_client.rs`:
- Around line 1650-1656: The close-path is still clearing the send backlog
before we snapshot it, so did_abrupt_close sees bufferedAmount == 0; update the
flow so the queued byte count is captured before clear_data() is invoked: call
Self::buffered_amount(self) (or otherwise read the internal send-queue length)
prior to handle_close()/clear_data(), and pass that captured value into
CppWebSocket::opaque_ref(...).did_abrupt_close(code, buffered) (or modify
dispatch_abrupt_close to accept the buffered value) so the abrupt-close event
reports the true bufferedAmount; relevant symbols: Self::buffered_amount,
handle_close, clear_data, dispatch_abrupt_close, CppWebSocket::opaque_ref,
did_abrupt_close.

🪄 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: ae7ac404-3c38-4485-b966-744e0ae8211a

📥 Commits

Reviewing files that changed from the base of the PR and between 83525d3 and 4d50532.

📒 Files selected for processing (7)

• src/http_jsc/websocket_client.rs
• src/http_jsc/websocket_client/CppWebSocket.rs
• src/http_jsc/websocket_client/WebSocketProxyTunnel.rs
• src/http_jsc/websocket_client/WebSocketUpgradeClient.rs
• src/jsc/bindings/webcore/WebSocket.cpp
• src/jsc/bindings/webcore/WebSocket.h
• test/js/web/websocket/websocket-buffered-amount.test.ts

[robobun]

Diff is green — the only red lane is `darwin-14-x64-test-bun`, failing on unrelated third-party/flaky tests (`grpc-js/test-tonic` — the unzipper-downloaded test server failed to start with FILE_ENDED; plus `bake/serve-plugins-dev-server` and `serve-body-leak` which already passed on retry on the ASAN lane). None of these touch the WebSocket client code this PR changes.

All WebSocket coverage passes, including the new `websocket-buffered-amount` tests on every lane (debian-13-x64-asan, darwin-26-aarch64, all Windows, alpine, ubuntu). The earlier macOS/Windows flake in my own test was fixed in c758473 (relaxed the close() assertion to `>=`, since close() queues an ~8-byte close frame).

I have already used my one CI re-roll (83525d3), so per policy I am not pushing another retrigger. This needs a maintainer to re-run the `darwin-14` lane / merge past the unrelated third-party flake. All 12 review threads (CodeRabbit + claude findings) are resolved.

[robobun]

Still green on the diff. Latest build (#60169) failed only on `darwin-14-x64-test-bun`, and every failing test there is unrelated flake on a different subsystem — `cli/install/migration/complex-workspace`, `cli/update_interactive_install` (package-manager/registry), `http/serve-body-leak` (ASAN memory threshold), and `jsc-stress/simd-baseline` — all tagged flaky/passed-on-retry. My last commit was a comment-only doc change (no logic), so nothing here can be caused by this PR.

The WebSocket `bufferedAmount` tests pass on every lane that finished (debian-13-x64-asan, all Windows lanes, etc.). I have already used my one CI re-roll (83525d3); per policy I am not pushing another retrigger. All 13 review threads are resolved — this just needs a maintainer to merge past the unrelated `darwin-14` flakes.

[robobun]

Still green on the diff. Build #60171 flagged `debian-13-x64-asan-test-bun`, failing only on unrelated flaky tests — `cli/install/bunx` ("package that requires node 24", an npm-download test) and `node/http/node-http-connect` (tagged flaky) — neither of which touches WebSocket code; that lane is now passing on retry. My last two commits were comment-only (doc wording), so nothing here can be caused by this PR.

The WebSocket `bufferedAmount` tests pass on every lane that finished. I already used my one CI re-roll (83525d3); per policy I am not pushing another. All 14 review threads (CodeRabbit + claude) are resolved and CodeRabbit’s latest review found no actionable comments with all pre-merge checks green. This just needs a maintainer to merge.

[robobun]

Diff is green; CI build #60171 hit a broad flake wave across many unrelated subsystems — the failing tests are `cli/install/bunx`, `cli/run/no-orphans`, `bun/cron/in-process-cron`, `bun/spawn/spawn-stdin-readable-stream`, `node/http/node-http-connect`, `web/fetch/fetch`, `web/streams/streams-leak`, and `napi/napi`, all tagged flaky/warning. None touch WebSocket code, and the spread across unrelated areas (install, cron, spawn, fetch, napi, …) is characteristic of a CI-infra/registry hiccup, not this PR. My last two commits were comment-only (doc wording), so nothing here can be caused by this change.

The WebSocket `bufferedAmount` tests are not among the failures and pass on every lane. I already used my one CI re-roll (83525d3); per policy I am not pushing another retrigger. All 14 review threads are resolved and CodeRabbit’s latest review found no actionable comments with all pre-merge checks green. This needs a maintainer to re-run CI / merge past the unrelated flake wave.

[Jarred-Sumner]

@robobun fix the lint failures too

[robobun]

Done, pushed in 31104c4.

The red Lint JavaScript check is a repo-wide break, not from this PR's code. #32522 switched the lint script from bunx oxlint (which auto-downloads) to a bare oxlint that resolves from node_modules/.bin, but .github/workflows/lint.yml never runs bun install, so every PR since then fails with oxlint: command not found. I added a bun install step to that workflow (matching format.yml and clippy.yml) and aligned its pinned Bun version to 1.3.2 like those two. bun lint is clean locally after install (0 warnings, 0 errors on src/js).

This PR's own code was already lint-clean: cargo clippy --workspace and the Format job (prettier + clang-format + cargo fmt) both pass, which I also re-verified locally.

[robobun]

Status update: rebased onto main after #40566 landed the live client bufferedAmount. This PR is now the close-path follow-up: it keeps the value from resetting to zero after terminate() and abnormal closes, and completes the post-close accounting for the Blob and no-argument overloads.

• The merged test file runs the 7 live-tracking tests from WebSocket client: pause()/resume(), working bufferedAmount, and a ServerWebSocket drain stall fix #40566 plus 9 retention tests from this PR. 5 of the retention tests fail on main and pass here. The full websocket suite passes locally.
• All review threads are resolved. The remaining CI red in earlier builds was unrelated to this diff and is reported for triage on main.

[claude]

I reviewed this PR and the automated bug-hunt found no issues in the current revision. Given the FFI signature changes (WebSocket__didAbruptClose/WebSocket__didClose) and the number of close/teardown paths threaded across the Rust↔C++ boundary, a maintainer sign-off is still warranted.

What was reviewed:

• Every close path (fail, handle_close, dispatch_close, dispatch_abrupt_close, finish_pending_close, terminate, send_close_with_body) snapshots buffered_amount() before clear_data() frees the send buffer; the C++ side keeps std::max so a stale 0 cannot regress the snapshot.
• buffered_amount() uses short RefCell::borrow()/JsCell::get() reads only — no re-entrancy hazard from the JS getter inside onmessage; the tunnel accessor is likewise a JsCell read.
• send_buffer_out()'s Err(true) arm restores buf before terminate() so fail()'s snapshot sees the backlog; the documented tunnel-only gap (synchronous on_close inside write_data) is a no-regression edge case.
• clampToUnsigned before saturateAdd in the Blob overloads prevents the >4 GiB narrowing wrap; getFramingOverhead(payloadSize) still takes the full size_t so the overhead tier is correct.

Extended reasoning...

Overview

This PR wires up client WebSocket.bufferedAmount, which was previously hard-wired to 0. It spans 8 files: the Rust WebSocket client (websocket_client.rs, CppWebSocket.rs, WebSocketProxyTunnel.rs, WebSocketUpgradeClient.rs), the C++ WebCore layer (WebSocket.cpp/.h), the FFI header (headers.h), and a new 400-line test file. The core additions are (a) two new HOST_EXPORT FFI getters returning the live send-buffer + tunnel-write-buffer size, (b) a buffered_amount: usize parameter threaded through both extern "C" close callbacks so the C++ snapshot survives teardown, and (c) fixes to the Blob and no-arg ping/pong overloads' post-close accounting.

Security risks

None identified. The change is a read-only accessor over an internal buffer plus bookkeeping of a byte counter; no user input parsing, no allocation sizing driven by untrusted data, no auth/TLS-verification changes. The clampToUnsigned helper correctly guards the size_t→unsigned narrowing for the >4 GiB Blob case before it reaches saturateAdd.

Level of scrutiny

High. This is not a mechanical change: it modifies the ABI of two extern "C" functions on both sides of the Rust/C++ boundary, adds two new FFI exports, and touches every close/abort teardown path in the native WebSocket client — code that has historically been sensitive to ordering (snapshot-before-clear_data), re-entrancy (tunnel on_close firing inside write_data), and RefCell borrow discipline. The PR went through 20 iterations with a dozen prior bug-hunter findings (all resolved), and the author bot itself flagged that a maintainer sign-off is needed for the FFI surface. That is well outside the "simple/mechanical" bar for auto-approval.

Other factors

• All prior inline findings from earlier review rounds are resolved; the current diff reflects the fixes (e.g. the send_buffer.replace(buf) restore before terminate, the buffered_override parameter on dispatch_abrupt_close for the handle_close path, the std::max in didClose).
• The one deliberately unaddressed edge case (tunnel SslWrapper::write_data fatal error firing on_close synchronously before the buffer restore) is documented in-source as a KNOWN GAP with a stated rationale; it is a no-regression window, not a new bug.
• Test coverage is thorough (8 cases: live growth, drain-to-0 while open, retention across close()/terminate()/protocol-error/server-Close/abrupt-socket-close, and the Blob/no-arg overloads), all verified failing on main and passing on the branch under both ASAN-debug and release.
• No outstanding unresolved reviewer comments.

[robobun]

Thanks for the review. Nothing new to address in 6094d96: the rebase onto main kept every close-path snapshot, the bufferedAmount tests pass locally (9/9 with the fail-before checks verified against the unfixed build), and all review threads are resolved. The remaining CI red is unrelated to this diff and is reported for triage on main. Agreed on the maintainer sign-off for the FFI surface; the PR is ready for it.

[claude]

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

• 🟡 src/http_jsc/websocket_client.rs:1323-1325 — Stray double blank line between has_tcp() and write_string() (lines 1323-1324) — rustfmt normalizes consecutive blank lines to one, so cargo fmt --all --check in the Format CI job will fail. Delete one blank line (likely a rebase artifact).

  Extended reasoning...

  What the issue is

  The diff hunk at @@ -1291,12 +1321,13 @@ inserts a lone + line, leaving two consecutive blank lines between the closing brace of has_tcp() and pub(crate) fn write_string(...). rustfmt collapses consecutive blank lines between items to at most one (the default blank_lines_upper_bound = 1), and the repo's rustfmt.toml only sets an ignore list — it does not override that default. The CI Format job runs cargo fmt --all --check via the pinned nightly toolchain, so this will produce a diff and exit non-zero.

  Code path

  In the checked-out file, cat -A shows lines 1323 and 1324 are both empty:

      }$
  $
  $
      pub(crate) fn write_string(this: ThisPtr<Self>, str: &EncodedSlice, op: u8) {$
  

  Running rustfmt --check on the file confirms rustfmt flags exactly this spot:

  Diff in src/http_jsc/websocket_client.rs:1320:
           let tcp = self.tcp.get();
           !tcp.is_closed() && !tcp.is_shutdown()
       }
  -
  
       pub(crate) fn write_string(this: ThisPtr<Self>, str: &EncodedSlice, op: u8) {
  

  Why nothing else prevents it

  rustfmt.toml contains only ignore = ["/vendor", "/test", "/build"]; src/http_jsc/websocket_client.rs is not in an ignored directory, and no blank_lines_upper_bound override is set. The timeline comment claiming "lint/clippy/format are green" was for commit 763114a; the current tip (after two subsequent rebases including 5099bb6 / ebbe330) introduced this stray line — the diff hunk explicitly shows it as a + addition against a context blank.

  Step-by-step proof

  1. rustfmt's default blank_lines_upper_bound is 1 (both stable and nightly).
  2. Repo rustfmt.toml does not override it — only sets ignore for /vendor, /test, /build.
  3. src/http_jsc/websocket_client.rs:1323-1324 are two consecutive empty lines between two fn items in the same impl block.
  4. rustfmt --check on this file emits a diff removing one blank and exits 1 (verified locally, output above).
  5. CI's Format job runs cargo fmt --all --check, which formats every workspace crate root and follows mod declarations — websocket_client.rs is reachable from the bun_http_jsc crate root.
  6. Therefore the Format job fails.

  Impact and fix

  Trivial: the Format CI check goes red until one of the two blank lines is deleted. No runtime behavior is affected. This is almost certainly a rebase artifact from the recent merges onto main (the PR description's "Rebase note" section documents multiple rebases over #40002/#40018/#40055).

  Fix: delete one of the two blank lines at src/http_jsc/websocket_client.rs:1323-1324 (or just run cargo fmt).

[robobun]

The stray blank line at src/http_jsc/websocket_client.rs:1323 was a rebase artifact from the removal of write_blob. The autofix commit 69128b4 already deleted it, so the Format check passes on the current tip.

[claude]

I reviewed this PR and the automated bug-hunt found no issues. Given the FFI ABI change (new size_t bufferedAmount parameter on WebSocket__didClose/WebSocket__didAbruptClose, plus two new getter exports) and the close-path threading across Rust and C++, a maintainer look is still warranted before merge.

What was reviewed:

• Snapshot ordering on every close path (fail, handle_close, send_close_with_body, finish_pending_close, terminate()) — each reads buffered_amount() before clear_data() frees the buffer.
• send_buffer_out() Err(true) branch now restores buf before terminate() so fail()'s snapshot is non-zero; clear_data() frees it, so no leak.
• FFI signatures match on both sides (usize ↔ size_t); clampToUnsigned guards the size_t→unsigned narrowing; didClose/didFailWithErrorCode keep the max so a late 0 cannot regress the snapshot.
• buffered_amount() re-entrancy from inside onmessage/onclose — uses RefCell::borrow() on send_buffer and JsCell::get() on the tunnel, both shared-borrow-safe under the current &self receiver model.

Extended reasoning...

Overview

This PR implements the client WebSocket.bufferedAmount getter, which was previously hard-wired to 0. It touches 8 files: the Rust WebSocket client (websocket_client.rs, CppWebSocket.rs, WebSocketProxyTunnel.rs, WebSocketUpgradeClient.rs), the C++ WebCore::WebSocket (WebSocket.cpp/.h), the FFI header (headers.h), and a new 400-line test file. The core change is (a) two new HOST_EXPORT getters that read the send buffer's readable length plus the proxy tunnel's write buffer, (b) an added size_t bufferedAmount parameter threaded through both did_close and did_abrupt_close FFI callbacks so every close path snapshots the backlog before clear_data() frees it, and (c) the C++ getter now queries the live client while attached and falls back to m_bufferedAmount once detached. It also brings the Blob and no-arg ping/pong overloads in line with their siblings for post-close accounting.

Security risks

None identified. The new getter is read-only over an existing in-process buffer; no user-controlled input reaches new parsing or allocation. The clampToUnsigned helper prevents a >4 GiB Blob size from wrapping when narrowed to unsigned for saturateAdd.

Level of scrutiny

High. This is not a mechanical change: it modifies the C ABI of two existing extern "C" callbacks (every Rust caller and the C++ implementations must agree on the new arity), and it threads state through every close/teardown path in a refcounted, re-entrant Rust struct where ordering vs. clear_data() matters. The PR has been through 23 review iterations with many aliasing/ordering findings (all resolved), and the author bot itself has twice noted the FFI surface warrants maintainer sign-off.

Other factors

All prior inline review threads (including mine on aliasing, snapshot ordering, and the send_buffer_out restore) are resolved. The test file covers eight distinct close paths (graceful, terminate, abrupt protocol error, server-initiated, socket destroy, drain-while-open, drain-after-close, Blob-after-close) and the gate evidence shows all fail on main and pass on the branch. The one documented gap (tunnel-mode fatal SSL error mid-flush snapshotting 0) is called out in a comment and is no worse than pre-feature behavior. Nothing here is simple enough for auto-approval, but nothing blocks merge either — this is a defer for the FFI/close-path surface, not for an outstanding concern.

[robobun]

Thanks for the review. Nothing to address in this round: the rebase over the RefPtr Drop change (#40478) kept every close-path snapshot, the bufferedAmount tests pass locally, and all review threads are resolved. The PR stays ready for a maintainer to sign off on the FFI surface.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

[robobun]

Thanks for the review. The reworked diff (close-path retention plus post-close overload accounting on top of #40566) is unchanged since the last push and all review threads are resolved. Ready for a maintainer.

[Jarred-Sumner]

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

Superseded by #45223 (reworked).

Real against the spec text (5 of the 9 tests fail on main), though Node resets bufferedAmount to 0 at close as well, and #31760 is closed.

The connected client now has one exit, finish() in websocket_client.rs, so the snapshot is taken there once and travels as an argument of didClose / didFail: no Option<usize> override, no std::max over three values, no "KNOWN GAP" comment.

After close only the payload bytes of send() count. This PR spread the "payload + framing" rule to Blobs and added 6 bytes per ping(); send("abc") after close was +9 on main, the spec says +3.

Tests: websocket-buffered-amount.test.ts "keeps what was never sent after ..." (4 cases), websocket-close-async-dispatch.test.ts (exactly 8, a Blob adds 4).