Take the native blob path for Response-wrapped Bun.file() streams

[alii]

What does this PR do?

new Response(Bun.file(p).stream()) always rendered through the per-chunk JS streaming loop, never the blob/sendfile path that new Response(Bun.file(p)) takes. Worse, wrapping a sliced file's stream broke outright on released Bun:

// stalls until idleTimeout, then resets the connection:
Bun.serve({ fetch: () => new Response(Bun.file(p).slice(100, 1124).stream()) });

// never resolves (for files ≳1MB):
await new Response(Bun.file(p).slice(100, 1124).stream()).bytes();

// resolves an ArrayBuffer instead of a Uint8Array:
await new Response(Bun.file(p).stream()).bytes();

Root cause: Body::extract stores file-source streams as Value::Locked, and check_body_stream_ref then migrates the stream from Locked.readable into the JS-side cached slot to break a GC cycle. Every later to_blob_if_possible call reads only Locked.readable, finds it empty, and silently fails — the conversion that would route file streams onto the blob path was dead code.

Changes (all on that one root cause)

• ReadableStream::to_any_blob (File arm): restore the FileReader's slice window (start_offset/max_size) onto the rebuilt Blob. It previously spanned the whole store, which would have served the entire file for new Response(file.slice(a,b).stream()) the moment the conversion became reachable.
• Body.rs: new BodyMixin::try_blob_from_resolved_stream — retries the blob conversion with a stream resolved from either slot. Wired into all five body consumers (text/json/arrayBuffer/bytes/blob). Bails out when the body already has a promise/action/on_receive_value, or when the stream is locked or disturbed, so user-observable streaming semantics are unchanged.
• RequestContext::do_render_with_body: the Source::Blob | Source::File render arm tries the same conversion before falling back to the JS streaming loop, so file streams reach the existing sendfile machinery. The pre-existing locked-stream check still runs first.
• ReadableStream::to_any_blob (File arm): force_detach the JS stream after a successful conversion. The FileReader keeps its lazy store (the converted blob only clones it), so a captured stream reference could otherwise be wrapped into a new Response and re-read the file from disk. Detaching leaves the stream in the exact state the JS streaming path leaves consumed file streams in: disturbed and locked, new Response(stream) throws "ReadableStream has already been used". (Blob/Bytes sources keep their existing post-conversion semantics — readable-stream-blob-consumed.test.ts pins those.)
• ValueBufferer::buffer_locked_body_value: blob/file-source streams that check_body_stream_ref migrated into the JS-side cache reached the // toBlobIfPossible should've caught this → unreachable!() and panicked the process — new HTMLRewriter().on(...).transform(new Response(Bun.file(p).stream())) crashes released Bun. Convert them there and re-dispatch through the existing Blob arm (buffered bytes / async file read).
• RequestContext::do_render_head_response: the HEAD render path had the same dead to_blob_if_possible shape, which would have made HEAD reply Transfer-Encoding: chunked while GET replies Content-Length for the same handler. Run the same conversion there so HEAD and GET report identical headers.
• Blob::resolve_size/resolved_size (File arm): a concrete slice size was clobbered with store_size - offset, widening the view to the end of the file — HEAD on new Response(Bun.file(p).slice(a,b)) (pre-existing) and .slice(a,b).stream() reported the store-wide length while GET served the slice. Apply the same only-resolve-unknown/clamp guard blob: stop resolve_size() widening a sliced Blob to the end of its store #31210 added to the Bytes arm.
• Reader-locked guards: a reader created with new ReadableStreamDefaultReader(body) (which, unlike getReader(), doesn't run the deferred $start thunk that marks lazy native streams disturbed) could have the stream converted and consumed/served out from under it, because the native ReadableStream::isLocked never matched real readers. This PR originally shipped a scoped ReadableStream__hasReader for its new conversion sites; after webcore: fix ReadableStream::isLocked never matching any stream #31884 fixed isLocked globally on main, that duplicate was dropped and try_blob_from_resolved_stream uses is_locked directly, with the pre-existing is_locked checks ahead of the ValueBufferer and do_render_with_body arms now live and rejecting reader-held streams before the arms run.
• get_form_data + spawn stdio (the last two consumers of the dead path): get_form_data now runs the conversion and, for file-backed (and S3) blobs, stamps the body's content type onto the blob and takes Blob::to_form_data's async read-then-parse path instead of synchronously parsing the empty in-memory view — also fixing pre-existing Response(Bun.file(p)).formData() (urlencoded silently resolved empty, multipart rejected "missing final boundary", missing files resolved empty instead of rejecting). Spawn stdio's Request/Response arms convert before extract_body_value, so stdin: new Response(Bun.file(p).stream()) (previously hung forever) delivers the file. Routing formData through the read path surfaced a pre-existing leak under LeakSanitizer: to_form_data_with_bytes ignored its lifetime parameter (as the Zig original did) and never reclaimed the Temporary read buffer, unlike every sibling *_with_bytes arm; it now frees it (and the synchronous call site passes Share for its store-backed view, which it never owned).

Observable effects

case	before	after
Bun.serve + Response(file.stream())	Transfer-Encoding: chunked, per-chunk JS loop	Content-Length, native blob/sendfile path
Bun.serve + Response(file.slice(a,b).stream())	stalls until idleTimeout → ECONNRESET	serves exactly the slice with Content-Length
Response(file.stream()).bytes()	resolves ArrayBuffer	resolves Uint8Array (as specified)
Response(file.slice(a,b).stream()).bytes()/.text()	never resolves (≳1MB files)	resolves with the slice
HTMLRewriter().transform(Response(file.stream()))	panic (unreachable!())	works
HEAD on a Response(file.stream()) handler	Transfer-Encoding: chunked	same Content-Length as GET
HEAD on a sliced Bun.file() / sliced stream handler	store-wide Content-Length (blob) / chunked (stream)	the slice's Content-Length, same as GET
re-wrapping a consumed file stream in a new Response	throws (streaming path)	still throws ("already been used")
stream locked/disturbed by user JS	streaming/error semantics	unchanged (guards verified by tests)
consumption with a new ReadableStreamDefaultReader(body) attached	file: rejected via the JS path; blob: stolen	rejects "ReadableStream is locked" uniformly; HTMLRewriter errors instead of panicking
serving a reader-held stream	200 sent, then mid-stream error and truncated body	rejected before headers with ERR_STREAM_CANNOT_PIPE (500), per the now-working locked check from #31884
Response(Bun.file(p)).formData()	silently empty FormData / "missing final boundary" (pre-existing)	parses the file; missing files reject
spawn({ stdin: new Response(file.stream()) })	hangs forever	delivers the file contents

Related issues, verified against this build:

• stream on sliced Bunfile doesn't work #18192 (direct Bun.readableStreamToText(file.slice(a,b).stream()) hang, no Response involved) is a separate FileReader bug and is not fixed here — the repro still hangs on this branch.
• Response.clone().bytes() returns incorrect ArrayBuffer instead of Uint8Array #30797 (Response.clone().bytes() returning ArrayBuffer) is the clone/tee variant of the type bug. Cloned bodies go through the JS readableStreamToBytes multi-chunk path, whose concatArrayBuffers arg-order bug is fixed separately in webstreams: return ArrayBuffer from single-string-chunk arrayBuffer() consumer #30810 — the clone repro still returns ArrayBuffer on this branch, so neither issue should be auto-closed by this PR.

Tests

• test/js/web/fetch/body.test.ts: 15 new tests — Uint8Array type + full contents, sliced .bytes() exact-window content (position-dependent file data), sliced .text()/.arrayBuffer(), disturbed-stream construction throw pin, locked-reader rejection pin, response.body.cancel() pin (bodyUsed flips, consumption rejects with "Body already used", same as released Bun), an exposed-.body pin (after .bytes() the previously returned stream is consumed and unusable — locked === true, reads throw "ReadableStream is locked", re-wrap throws — byte-for-byte the streaming path's end state), a re-wrap pin (a consumed file stream can't be wrapped into a new Response and re-read), raw-constructor-reader rejection pins for file- and blob-backed bodies (locked, not disturbed — the stream must not be stolen), and 5 .formData() tests (file-stream parse, direct file-backed body parse, multipart direct+stream, missing-file rejection, and a no-steal pin for a failed encoding check).
• test/js/bun/http/serve.test.ts: 7 new tests — Content-Length + body equality for streamed file, sliced stream serves exactly the slice, HEAD/GET Content-Length parity, cannot-pipe error-semantics pins for reader-held streams (subprocess; getReader() and raw-constructor variants; rejected before headers with a 500 since webcore: fix ReadableStream::isLocked never matching any stream #31884), 100 aborted-mid-transfer requests (mirroring the existing sendfile abort test) followed by a full-body fetch, and a client reader.cancel() mid-transfer followed by a full-body fetch.
• test/js/workerd/html-rewriter.test.js: (from file stream) supports element handlers — crashes released Bun with the unreachable!() panic, passes with the fix — and a reader-held variant that errors Stream already used instead of panicking/stealing.
• test/js/bun/spawn/spawn.test.ts: 2 new tests — Response/Request-wrapped file streams as stdin (both hang by timeout on the unfixed build).
• USE_SYSTEM_BUN=1: the fix-proving tests fail on released Bun (wrong type ×2, chunked encoding, timeout hangs for sliced consumption and wrapped-stream stdin, the HTMLRewriter panic, and the silent-empty/multipart-error formData cases); the behavior pins (cancel, abort, re-wrap rejection, locked/disturbed semantics, failed-encoding no-steal) pass on both.
• Full local gauntlet on the patched debug build: serve.test.ts, serve-static.test.ts, body*.test.ts (all five), response.test.ts, streams.test.js — 9,745 pass / 0 fail.

[robobun]

^{Updated 12:17 AM PT - Jun 10th, 2026}

❌ @robobun, your commit 26fdee3 has 1 failures in Build #61608 (All Failures):

• test/js/web/websocket/autobahn.test.ts - code 1 on 🍎 14 aarch64

---

🧪   To try this PR locally:

bunx bun-pr 31674

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

bun-31674 --bun

[alii]

@robobun adopt

[github-actions]

Found 2 issues this PR may fix:

1. Response.clone().bytes() returns incorrect ArrayBuffer instead of Uint8Array #30797 - PR fixes .bytes() returning ArrayBuffer instead of Uint8Array for file-backed Response streams, which matches this report about Response.clone().bytes() returning the wrong type
2. stream on sliced Bunfile doesn't work #18192 - PR fixes new Response(file.slice().stream()) hanging in Bun.serve and body consumers for large files, which matches this report about sliced BunFile streams not working for files > 640K

If this is helpful, copy the block below into the PR description to auto-close these issues on merge.

Fixes #30797
Fixes #18192

🤖 Generated with Claude Code

[Jarred-Sumner]

Can you add a test that checks stream.cancel wroks? And that aborting the request works still?

[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

Convert unlocked resolved file/blob ReadableStreams into AnyBlob (preserving slice offsets/sizes); body consumer accessors and RequestContext use blob-backed paths when possible and fall back to streaming. Update Blob EOF-clamping and add tests for full/sliced file responses, locking, cancelation, and HTMLRewriter on streamed files.

Changes

File-backed stream blob conversion

Layer / File(s)	Summary
ReadableStream slice restoration in blob conversion src/runtime/webcore/ReadableStream.rs	The to_any_blob File branch reapplies FileReader start_offset/max_size to the constructed Blob and force-detaches the stream to drop the native pointer in the consumed state.
Body mixin helper for stream-to-blob conversion src/runtime/webcore/Body.rs	Adds BodyMixin::try_blob_from_resolved_stream which tries to convert an unlocked resolved ReadableStream into an AnyBlob, detaches the native readable, and replaces the body Value on success.
Body accessor methods using stream conversion src/runtime/webcore/Body.rs	get_text, get_json, get_array_buffer, get_bytes, and get_blob_with_this_value attempt the stream->blob conversion first and only set streaming Actions when conversion fails; get_form_data avoids conversion.
ValueBufferer locked handling src/runtime/webcore/Body.rs	ValueBufferer::buffer_locked_body_value now converts Source::Blob/Source::File locked bodies to AnyBlob when possible and re-runs buffering through the blob path.
Locked-body rendering for file-backed streams src/runtime/server/RequestContext.rs	do_render_head_response and do_render_with_body special-case locked Source::Blob/Source::File to try to_any_blob/try_blob_from_resolved_stream; on success they switch to the blob render path, otherwise they fall back to streaming via do_render_stream and StreamPair.
Blob size EOF-clamping for seekable files src/runtime/webcore/Blob.rs	resolve_size/resolved_size now compute an EOF-clamped available remainder and set unknown sizes to available or clamp known sizes to available rather than unconditionally using store_size - offset.
Response helper wrapper src/runtime/webcore/Response.rs	Adds Response::try_blob_from_resolved_stream delegating to BodyMixin::try_blob_from_resolved_stream.
File-backed stream response tests test/js/bun/http/serve.test.ts, test/js/web/fetch/body.test.ts, test/js/workerd/html-rewriter.test.js	Add tests verifying Response wrapping Bun.file().stream() and sliced streams use content-length for native file streams, serve full and sliced contents correctly, preserve locked/abort/cancel semantics, and support HTMLRewriter on streamed file responses.

• Possibly related PRs:
  • oven-sh/bun#31210: Addresses related slice/window preservation and serialization behavior for sliced Blobs.

Suggested reviewers

• cirospaciari

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Take the native blob path for Response-wrapped Bun.file() streams' accurately captures the main change—routing file-backed streams through the native blob/sendfile path instead of the JS streaming loop.
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.
Description check	✅ Passed	The PR description comprehensively documents the bug, root cause, all code changes, observable effects, test coverage, and known limitations.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

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

[coderabbitai]

Actionable comments posted: 4

🤖 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/runtime/webcore/Body.rs`:
- Around line 1792-1823: The function try_blob_from_resolved_stream should not
convert/detach the original ReadableStream once the JS-visible body cache has
been populated; add a guard at the start of try_blob_from_resolved_stream to
check the JS body cache (the same condition used by body_get_cached(js_ref) /
body_get_cached) and return false if that cache exists so we keep the streaming
path intact. Specifically, in try_blob_from_resolved_stream (and before calling
stream.to_any_blob or detach_readable_stream) check the body cache via
get_body_value()/body_get_cached-equivalent and bail out when a cached JS body
is present, preserving the existing checks for
locked/promise/on_receive_value/action and stream.is_locked.

In `@test/js/bun/http/serve.test.ts`:
- Around line 2405-2412: The helper makeStreamFile uses tmpdirSync(); replace
that with the test harness tempDir helper: import tempDir from 'harness' (or add
it to the existing harness import) and call tempDir() to create the temporary
directory inside makeStreamFile, then use join(tempDir(),
"serve-file-stream.bin") as the path; update any references to tmpdirSync()
within makeStreamFile to use tempDir and keep the rest of the function (writing
bytes, returning { path, bytes }) unchanged.

In `@test/js/web/fetch/body.test.ts`:
- Around line 745-751: The helper function makeFile uses require("fs") inline;
replace this dynamic require with a module-scope import and call to that
imported binding: add a top-level import (e.g., import * as fs from "fs" or
const fs = require("fs") at module scope) and then update makeFile to call
fs.writeFileSync(path, bytes) instead of require("fs").writeFileSync(...); keep
the same function name makeFile, SIZE usage, and filename
"body-file-stream.bin".
- Around line 753-762: Replace inline dynamic requires with a module-scoped
import: add an import for tempDirWithFiles from "harness" at the top of the test
module, then remove the per-test uses of const { tempDirWithFiles } =
require("harness"); inside each test (these occur in the tests that call
tempDirWithFiles in the body test suite). Update all five occurrences so tests
instead call tempDirWithFiles directly; no other logic should change (tests like
the one using makeFile, file(path).stream(), and Response(...).bytes() remain
the same).

🪄 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: 48e123fa-2526-4e73-82fd-ca8bee4f1654

📥 Commits

Reviewing files that changed from the base of the PR and between 5836485 and b5828d0.

📒 Files selected for processing (5)

• src/runtime/server/RequestContext.rs
• src/runtime/webcore/Body.rs
• src/runtime/webcore/ReadableStream.rs
• test/js/bun/http/serve.test.ts
• test/js/web/fetch/body.test.ts

[robobun]

✅ Ready for review / merge. Head 26fdee3 has all requested work in:

• formData and spawn stdio now take the native blob path for file-backed body streams (8da2c60), with tests for both.
• The scoped has_reader helper is deleted in favor of main's global isLocked fix (webcore: fix ReadableStream::isLocked never matching any stream #31884); conversion sites use is_locked directly (6f07d3b).
• An ASAN-reported leak in the new formData read path is fixed (675d347); the debian x64-asan lane at this head reports no leaks.
• Merged current main, which also picks up the bunx.test.ts CI skip (Skip bunx.test.ts in CI until the Node.js version bump #32042).

CI (build 61608, final): 284 jobs passed, including every lane that exercises this diff (debian x64-asan, windows, darwin x64, darwin 26 aarch64, linux aarch64). Two red jobs, both unrelated to the diff:

• One darwin-14-aarch64 shard failed on overrides.test.ts (npm registry resolution), done-async/expect-assertions (test-runner meta-tests), and autobahn (docker WebSocket suite). None of these touch this PR's code paths, and all pass on the sibling shard and on darwin-26-aarch64 with the same binary; it looks like a bad agent.
• linux aarch64-android verify-baseline expired waiting for an agent.

Both need a Buildkite retry from someone with write access. All review threads resolved.

[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 `@test/js/workerd/html-rewriter.test.js`:
- Around line 168-179: Replace the manual tmpdirSync() usage with the harness
tempDir automatic-cleanup pattern: import tempDir from 'harness' and create the
temp directory via const dir = using(tempDir()), then build the file path using
join(dir.path, "html-rewriter-stream.txt.js") and write the file there; keep the
rest of the test (HTMLRewriter, response stream, and assertions) unchanged so
cleanup happens automatically via Symbol.dispose on dir.

🪄 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: 54f70555-89cf-4bac-b943-819db5ff774a

📥 Commits

Reviewing files that changed from the base of the PR and between ac2acbf and 95fae83.

📒 Files selected for processing (5)

• src/runtime/webcore/Body.rs
• src/runtime/webcore/ReadableStream.rs
• test/js/bun/http/serve.test.ts
• test/js/web/fetch/body.test.ts
• test/js/workerd/html-rewriter.test.js

[alii]

@robobun fix review comments

[robobun]

Done in 8da2c60. Every review thread was already addressed in code except the two findings I had deferred with in-thread verification; both are now fixed:

• .formData(): get_form_data runs the stream-to-blob conversion, and file-backed (and S3) blobs take Blob::to_form_data's async read-then-parse path with the body's content type stamped on the blob. This also fixes pre-existing Response(Bun.file(p)).formData(): urlencoded silently resolved an empty FormData, multipart rejected with "missing final boundary", and missing files resolved empty instead of rejecting with ENOENT.
• spawn stdio: the Request/Response arms convert before extract_body_value, so stdin: new Response(Bun.file(p).stream()) (which previously hung forever) now delivers the file.

7 new tests (5 formData in body.test.ts, 2 stdin in spawn.test.ts); the fix-provers hang or resolve-empty on the unfixed build. Replies with details are on the two original threads.