[robobun]

Related to #43931

Problem

• socket.write(s3file) returns 0 on a Bun.connect / Bun.listen socket. socket.end(s3file) returns 0 and closes the connection. Nothing is sent, and nothing throws.
• The guard in NewSocket::write_or_end (src/runtime/socket/socket_body.rs:2894) tests needs_to_read_file(), true for a file store only. buffer.slice() is empty for an S3 store.

Fix

• write_or_end reads the payload once: let Some(data) = buffer.in_memory_view() else { throw }.
• The throw is the plain Error of WebSocket.send (WebSocket: real closing handshake, one failure path, ws rewritten on native transports (consolidates the open WebSocket PRs) #45223): Socket.write cannot send a file- or S3-backed Blob synchronously; await blob.bytes() first. It comes before the socket sends or ends.
• Verified: test/js/bun/net/socket.test.ts (2 of 4 new tests fail on main). Also the whole file (Notes).
• Self-reviewed: 13 concerns raised, 12 addressed. The base stays main (Notes).

Background

• A Blob views a store: bytes, a file, or an S3 key. BlobExt::in_memory_view() is None for the last two.
• write() is typed string | BufferSource, but native code also takes a Blob.
• net, tls: consolidate the open node:net, node:tls, Bun.connect, Bun.listen and usockets pull requests #46522 rewrites this function, keeps the guard, and leaves this change for a separate review. If it merges first, one line here needs a rebase (Notes).
• Considered || is_s3() in the guard: it keeps two reads behind a hand-written list of store kinds.

Downsides

• Behavior change: on Bun 1.4.4 these calls return 0, or -1 on a half-closed socket. Now they throw. No user reported the bug.
• write(x, byteOffset, byteLength) of a string or buffer costs 8 more instructions (787 to 795). write(string) costs 18 fewer.
• Not fixed: a printed Request with an S3 body still writes 0 (s3: leave the size of an S3 blob unknown in resolve_size #46653). A refused Request or Response is spent.

Notes

Origin. A fuzz run found it. #43931 described the class and was closed as not a user report. #46673 lists the other sites. #14516 wrote the guard before the S3 store existed (#15740). No S3 request is made before or after.

Repro. A loopback Bun.serve stands in for S3.

const log = [];
const srv = Bun.serve({ port: 0, hostname: "127.0.0.1", fetch(q) { log.push(q.method); return new Response("0123456789"); } });
const s3 = new Bun.S3Client({ endpoint: srv.url.href, accessKeyId: "k", secretAccessKey: "s", bucket: "b" });
let got = 0;
const peer = Bun.listen({ hostname: "127.0.0.1", port: 0, socket: { data(_, d) { got += d.length; } } });
Bun.connect({ hostname: "127.0.0.1", port: peer.port, socket: { data() {}, open(s) {
  const t = f => { try { return "returned " + f(); } catch (e) { return "throws " + e.message; } };
  console.log("write(s3file):", t(() => s.write(s3.file("o")))); // 1.4.4 and main: returned 0
  console.log("end(s3file)  :", t(() => s.end(s3.file("o"))));   // 1.4.4 and main: returned 0, and the peer sees FIN
  setTimeout(() => { console.log("peer read", got, "bytes | S3 requests:", log.length); process.exit(0); }, 300);
} } });

What moves. The left column is the 1.4.4 release binary (38afee6) and main 6292c65: each row gave the same result on both. There, write(Bun.file(path)) throws File blob not supported yet in this function. "Lazy" is an S3File, a slice of one, new Blob([s3file]), new Response([s3file]), or a Request with such a body.

Call	Bun 1.4.4 and main	This PR
write(lazy)	returns 0	throws
end(lazy)	returns 0, the peer sees FIN	throws, the socket stays open
write(s3file, 0, 4)	ERR_OUT_OF_RANGE with a maximum of 0	throws the refusal
write(lazy) on a half-closed socket	returns -1	throws
write(Bun.file(path)), and a Request with that body	throws the old text	throws the new text
write(s3file.slice(0, 0))	returns 0	throws, like Bun.file(path).slice(0, 0)
a string, a buffer, an in-memory Blob, a buffered Request or Response	sent	the same

• The refusal comes where the type error for write(123) comes: before the socket state is read. A detached socket still returns -1.
• One exception: a Request or Response whose lazy body has a resolved size of 0 still writes 0, because to_blob() drops its store. That is a printed S3 body (s3: leave the size of an S3 blob unknown in resolve_size #46653), an empty slice of an S3 file, or an empty file whose size was read. For the last two, 0 bytes is the right result.
• new Response(s3file) (no array) has no buffered body. It throws Only buffered Request/Response bodies are supported for now. before and after.
• node:net is not affected. Its Writable refuses a Blob chunk with ERR_INVALID_ARG_TYPE, as Node does.

Tests. Debug (ASAN) build of this branch, Linux x64.

• "refuses a file- or S3-backed Blob, sends nothing and stays open", over tcp and tls: fails on the 1.4.4 release binary and on main (release build of 6292c65), passes here. It checks the error of write and end for six inputs and for an explicit range, a flush() and a later write on the same socket, and that the S3 stand-in saw no request before a sentinel read.
• "sends an in-memory Blob and the buffered body of a Request or Response, in order", over tcp and tls: the control. It passes on 1.4.4, on main and here. It fails if the new read refuses or misreads a Blob that is in memory, a sliced one included. It is the first test that pins a Blob, a Request or a Response as socket data.
• The whole file: 197 pass, 7 skip, 1 fail. The failure is should not call drain before handshake, which connects to www.example.com. This machine has no DNS, and the test fails the same way on main.
• I ran these on Linux x64 only. CI build 132356 passed on all 181 jobs, which include macOS, Windows and arm64.

Cost. Release builds (bun run build:release) of main 6292c65 with and without the commit, Linux x64. gdb stepi from the first instruction of NewSocket<false>::write_or_end::<false> to its return, callees included, 8 calls on one loopback connection. Every later call gave the same count. The counts leave out mimalloc, whose refill path adds 92 on some calls in both builds.

data	write(x)	write(x, 0, 1)
string	789 → 771	787 → 795
Uint8Array	679 → 669	685 → 693
in-memory Blob	540 → 498	526 → 522
new Response("ef")	1035 → 993	1021 → 1017
new Response(new Blob(["ef"]))	865 → 823	851 → 847

• First call of write("x"): 1414 to 1396. A string over TLS: 2933 to 2915. end("x"), from jsTCPSocketPrototypeFunction_end: 1442 to 1420.
• main reads the payload twice when byteLength is not given. The saving is that read.
• The 8 on an explicit range: the read now comes before the two integer conversions, and its pointer and length are saved across them. A variant that reads after the conversions measured the same (772 and 795), so the read stays where the guard was.
• On the head of net, tls: consolidate the open node:net, node:tls, Bun.connect, Bun.listen and usockets pull requests #46522 the same change measures 750 to 704 for write("x") and 737 to 736 for write("x", 0, 1).
• mimalloc calls per write_or_end, before and after: a string 0, an in-memory Blob 1 malloc and 1 free, new Response("ef") 3 and 3.
• A refused write(s3file) and a refused end(s3file) enter 0 syscalls (gdb catch syscall). On main, end(s3file) enters setsockopt, epoll_ctl and close, and no sendto.
• A refused call costs about 5,400 instructions and 8 mallocs. The Bun.file() refusal on main costs about 5,100 and 6: the message now has one formatted argument.
• Size (llvm-size -A, llvm-nm -S): .text 82,253,657 to 82,253,145. write_or_end::<false> 1902 to 1749 bytes (TCP) and 1958 to 1809 (TLS).

Other open PRs.

• net, tls: consolidate the open node:net, node:tls, Bun.connect, Bun.listen and usockets pull requests #46522: its owner keeps this change out of it and lists this PR under "Not included". The change to what these calls return gets its review here. One conflict, the default byteLength line. If net, tls: consolidate the open node:net, node:tls, Bun.connect, Bun.listen and usockets pull requests #46522 merges first, I rebase this PR and the line becomes data.len().saturating_sub(byte_offset). If this PR merges first, net, tls: consolidate the open node:net, node:tls, Bun.connect, Bun.listen and usockets pull requests #46522 gets that conflict.
• http: consolidate the open fetch, Bun.serve, node:http, node:http2 and HTTP/3 pull requests #46528 carries the same socket changes: the same one conflict.
• bindgen: delete b.any and .variadic #46789 rewrites how write() parses its data: one conflict in socket_body.rs and one in types.rs. The read has to stay a fallible one there.
• Refuse an S3-backed Blob at spawn stdin, in the shell, in Bun.build files and in redis #46673 edits the same use line of types.rs with the same text: no conflict. s3: leave the size of an S3 blob unknown in resolve_size #46653, Bun.Image: treat an empty Blob or buffer as zero bytes #46117 and Read Bun.serve integer options, socket.write offsets and matcher counts by value, so -0 is 0 #46212: none added.
• macros: read a returned Bun.file() on the transpiling thread and inline its bytes #46688 makes in_memory_view an inherent method. There is no textual conflict, but if it lands first, BlobExt as _ must leave the use line of types.rs (unused_imports is denied).
• Checked with git merge-tree against 8417dd1, 451c232, 23f74c5, c200a79, e8f1b97, 4a65696, 261fc5b and fd1fc8d.

Not in it.

• The node:http twin us_socket_buffered_js_write (src/runtime/socket/uws_jsc.rs:193) keeps the File-only guard. Only the private _write reaches it with a Blob, and http: consolidate the open fetch, Bun.serve, node:http, node:http2 and HTTP/3 pull requests #46528 deletes it.
• Bun.build files and redis arguments. They go through BlobOrStringOrBuffer::from_js (src/runtime/node/types.rs:153), which refuses a file store only. Refuse an S3-backed Blob at spawn stdin, in the shell, in Bun.build files and in redis #46673 fixes that parser.
• A Blob with more than one part: new Blob(["a", s3file]) still sends a (Blob constructor ignores File parts if more than one part is given #25851, Blob: read file-backed parts in multi-part new Blob([...]) #33600).
• A Blob whose content was moved into a body (new Response([blob]), then write(blob)) still writes 0 (Blob: share a body part's store instead of moving it out of the caller's Blob #46732).
• A FormData body with an S3-backed entry (FormData: throw when serializing an S3-backed entry instead of sending an empty part #38364).
• A Bun.build() output written to outdir is file-backed and has no bytes() yet (Add bytes() and image() to BuildArtifact, and take it as a Blob in FormData #45509).
• Types and docs: unchanged.

Self-review. It found that the first cut went too far. That cut also kept a refused Request body unread and refused a printed S3 Request. It made three empty file-backed bodies throw where 0 was correct, and it changed node:http's private _write. I removed it. The review also asked for the sentinel read, the flush(), the sliced control rows and this cost table. The one point I did not take: it asked for a PR based on the branch of #46522. I based it on main, so that it has CI against main and can merge on its own. Also considered: a throw in the argument parser. Every write would then pass the caller's name to it.

[robobun]

Status: reproduced on the Bun 1.4.4 release binary (38afee6) and on release and debug builds of main 6292c65. The script is in the Notes of the description. socket.write(s3file) returned 0. socket.end(s3file) returned 0 and the peer saw FIN. The S3 stand-in received no request.

The fix and its tests are in this PR: #46833. Its base is main. #46522 leaves this change for a separate review here. If #46522 merges first, I rebase this PR (one line conflicts).

[robobun]

^{Updated 8:36 PM PT - Oct 24th, 2026}

✅ @robobun, your commit 5534f6ccee0ed320a409406354b40b7246375f54 passed in Build #132356! 🎉

---

🧪   To try this PR locally:

bunx bun-pr 46833

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

bun-46833 --bun

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: oven-sh/bun
• Branch: robobun/3a525a1e/socket-refuse-lazy-blob
• File: .coderabbit.yaml
• Commit: 5534f6c
• Layers: Repository YAML
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: bd4220d8-b1e4-4723-ad7a-665fe683330d

Commits

Reviewing files that changed from the base of the PR and between 179664e and 5534f6c.

Files selected for processing: 3

• src/runtime/node/types.rs
• src/runtime/socket/socket_body.rs
• test/js/bun/net/socket.test.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 0 remain after this review.

Walkthrough

Socket.write() and Socket.end() now use in-memory byte views for synchronous payloads. They reject payloads without an in-memory view and direct callers to await blob.bytes(). TCP and TLS tests cover rejected payloads, in-memory payloads, and subsequent writes.

Changes

Socket payload handling

Layer / File(s)	Summary
Expose in-memory payload bytes src/runtime/node/types.rs	BlobOrStringOrBuffer now returns an optional in-memory byte view. Blob values use Blob::in_memory_view(); string and buffer values return their contained bytes.
Use views for socket writes and ends src/runtime/socket/socket_body.rs, test/js/bun/net/socket.test.ts	NewSocket::write_or_end rejects payloads without an in-memory view and uses the view for default lengths and byte-range slicing. TCP and TLS tests cover rejected file- or S3-backed blobs, successful in-memory payloads, and subsequent writes.

Possibly related issues

• oven-sh/bun#43381 — This change covers socket behavior after Socket.end() rejects an unsupported file- or S3-backed Blob.

Suggested reviewers: alii, cirospaciari, dylan-conway

Priority: Normal

Merge Risk: Minimal · up to 5534f

The change can merge after normal checks; no concrete unresolved risk has been established.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main change: refusing file- or S3-backed Blobs in socket write and end operations.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Description check		The description clearly explains the problem, implementation, scope, behavioral changes, limitations, and verification results. It does not use the exact template headings, but it provides the require…

Full details: Description check

Explanation

The description clearly explains the problem, implementation, scope, behavioral changes, limitations, and verification results. It does not use the exact template headings, but it provides the required information, including detailed test coverage and known environment-specific failure.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

Beyond the inline findings, I also checked the data slice borrowed at src/runtime/socket/socket_body.rs:2894 and held across the byteOffset/byteLength coercions — is_any_int and to_int64 are pure numeric checks that cannot run user JS, and buffer stays alive until the function returns, so the view cannot dangle. The default byteLength and the bytes source now reading data instead of buffer.slice() is identical for every in-memory input (both resolve to shared_view() / str.slice()), and the control test pins that for sliced and offset Blobs over both tcp and tls.

Extended reasoning...

The change replaces the File-only guard in the shared write/end body of NewSocket (both SSL variants, via the IS_END const generic) with a fallible BlobOrStringOrBuffer::in_memory_view() so S3-backed Blobs are refused with a thrown Error before any socket state is touched, and adds tcp/tls tests with a loopback Bun.serve as the S3 stand-in. It touches no auth, crypto, or injection surface. The refactor was verified behavior-preserving for in-memory inputs and the borrowed slice is sound, but the inline findings about sibling guards and the consumed Request/Response body are substantive enough that a human should weigh them before merging.

Additional findings (outside the current diff — GitHub can't attach inline comments there):

• 🟣 src/runtime/node/types.rs — pre-existing: callers that pass an S3File where a Bun.file() is refused still get empty bytes written silently, exactly as on the base branch. The sibling guards still test only needs_to_read_file(), which is false for an S3 store, so the blob passes and slice() yields nothing. Fix: route every file-or-S3 refusal through the same predicate the socket now uses (blob.in_memory_view().is_none()), which covers the 2 sites listed. Same pattern at 2 sites (src/runtime/node/types.rs:153, src/runtime/socket/uws_jsc.rs:193). Bun.build({ files: { "a.ts": s3file } }) then builds an empty module instead of throwing "File blob cannot be used here".

  Why this was flagged

  A user passes an S3File (client.file("key")) as a value in Bun.build's files option, which reaches BlobOrStringOrBuffer::from_js at src/runtime/api/JSBundler.rs:80 with FileBlobs::Reject. The guard at src/runtime/node/types.rs:153 checks only blob.needs_to_read_file(), which is false for an S3 store, so the S3File is accepted; JSBundler.rs:90 then copies blob_or_string.slice(), which is empty for an S3 store, and the virtual file is registered with zero bytes. A Bun.file(path) at the same spot throws "File blob cannot be used here". The node:http server socket write at src/runtime/socket/uws_jsc.rs:193 has the identical needs_to_read_file()-only guard and the identical empty-slice write at uws_jsc.rs:211. This PR fixes the third instance of the pattern in socket_body.rs:2894 with in_memory_view() but leaves these two unchanged; the description defers them to another issue. Behaviour is the same as on the base branch, so this is pre-existing, but the fix belongs in the shared helper so all three sites agree.

  Verification: pre-existing. Triggering condition: a user passes an S3File to any caller that parses with FileBlobs::Reject, e.g. a value in Bun.build's files option. src/runtime/node/types.rs:153 blob.needs_to_read_file() is false for store::Data::S3, so the S3 blob is accepted and slice() returns &[], so the virtual file is registered with zero bytes. The base branch fails the same way.

[robobun]

On the two sites outside the diff: both are excluded on purpose, and the description names them under "Not in it".

• src/runtime/node/types.rs:153 (from_js_maybe_file, used by Bun.build files and redis): Refuse an S3-backed Blob at spawn stdin, in the shell, in Bun.build files and in redis #46673 is open for it. It refuses a Blob whose in_memory_view() is None in that parser, with tests for both callers.
• src/runtime/socket/uws_jsc.rs:193 (us_socket_buffered_js_write): only node:http's private _write reaches it with a Blob, because the Writable refuses a Blob chunk first. http: consolidate the open fetch, Bun.serve, node:http, node:http2 and HTTP/3 pull requests #46528 deletes the function.

[Jarred-Sumner]

I said on #46522 that I'd fold this in, and I've decided against it. The change itself reads well; the reasons are about #46522.

• These calls return 0 (or -1) on the last release and would start to throw. That's a fair trade for a call that silently sends nothing, but it's a maintainer's decision, and it deserves its own review rather than a line in a 60 KB description.
• net, tls: consolidate the open node:net, node:tls, Bun.connect, Bun.listen and usockets pull requests #46522 and http: consolidate the open fetch, Bun.serve, node:http, node:http2 and HTTP/3 pull requests #46528 have just reached a stable point: no open review thread, and the last CI runs are green apart from one sick macOS agent. A change in socket_body.rs would restart CI and review on net, tls: consolidate the open node:net, node:tls, Bun.connect, Bun.listen and usockets pull requests #46522, and then need another merge into http: consolidate the open fetch, Bun.serve, node:http, node:http2 and HTTP/3 pull requests #46528 and another run there.

It stands well on its own with base main. #46522 rewrites write_or_end and keeps the old guard, so after it merges this needs a small rebase: the guard is the same four lines there. I've listed this PR under "Not included" in #46522.

[robobun]

This PR stays on base main and waits for its own review.

• The behavior change is the first bullet of Downsides. Every row of the table under "What moves" (Notes) now also ran on the 1.4.4 release binary (38afee6). There write and end return 0, or -1 on a half-closed socket. With this PR they throw, and the socket stays open.
• After net, tls: consolidate the open node:net, node:tls, Bun.connect, Bun.listen and usockets pull requests #46522 merges, I rebase this PR. A trial merge with 8417dd1 has one conflict, the default byteLength line, which becomes data.len().saturating_sub(byte_offset). The guard lines merge with no conflict.
• If this PR merges before net, tls: consolidate the open node:net, node:tls, Bun.connect, Bun.listen and usockets pull requests #46522, then net, tls: consolidate the open node:net, node:tls, Bun.connect, Bun.listen and usockets pull requests #46522 and http: consolidate the open fetch, Bun.serve, node:http, node:http2 and HTTP/3 pull requests #46528 get that one-line conflict.