fix: Bun.write with new Response(req.body) no longer hangs#28112
fix: Bun.write with new Response(req.body) no longer hangs#28112
Bun.write with new Response(req.body) no longer hangs#28112Conversation
|
Updated 7:38 PM PT - Mar 15th, 2026
❌ @claude, your commit d627ffc has 3 failures in
🧪 To try this PR locally: bunx bun-pr 28112That installs a local version of the PR into your bun-28112 --bun |
|
Note Reviews pausedIt 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 Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughPipes ReadableStream bodies directly into destination blobs, returns actual written byte counts, refines error and deinit paths for stream rejection, adds O_TRUNC for path opens, adjusts FileSink flag composition for truncate, and adds regression tests covering Response/ReadableStream write scenarios. Changes
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 📝 Coding Plan
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/bun.js/webcore/Blob.zig`:
- Around line 1416-1429: The direct piping fast-path for locked bodies can
bypass slice/offset semantics on sliced destination Blobs; update the branch
that uses response.getBodyReadableStream(globalThis) / bodyValue.Locked.readable
to only allow piping when the target destination_blob has offset == 0 (or
explicitly return an error/throw for non-zero offsets) before calling
destination_blob.pipeReadableStreamToBlob(globalThis, readable, ...); ensure you
perform the same guard in the analogous block around lines ~1494-1506 and keep
existing calls to destination_blob.detach() / readable.isDisturbed checks
intact.
In `@test/regression/issue/13237.test.ts`:
- Around line 12-13: The test currently calls Bun.write(outFile, new
Response(req.body)) and only verifies the file contents; update the regression
tests to also assert the return value of Bun.write (the byte count) to lock in
corrected semantics: capture the result of Bun.write in the blocks where
Response(req.body) is written (the occurrences using Bun.write with outFile and
new Response(req.body)) and add assertions that the returned number equals the
expected number of bytes written (e.g., the length of req.body or
expectedBuffer.byteLength); apply the same change to the other Bun.write
occurrences with Response(req.body) in this file so each write call has a
matching byte-count assertion.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: b08a93c4-d5ac-4b56-a4d2-3a67537cf738
📒 Files selected for processing (2)
src/bun.js/webcore/Blob.zigtest/regression/issue/13237.test.ts
|
Found 6 issues this PR may fix:
🤖 Generated with Claude Code |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
|
@robobun ci failure ❌ @claude, your commit 95e6ee6 has 2 failures in Build #39631 (All Failures): test/js/bun/util/v8-heap-snapshot.test.ts - SIGKILL on 🐧 25.04 x64 |
|
Updated 12:53 AM PT - Mar 15th, 2026
✅ All gates pass on CI: 55/55 test suites green. 3 failures are infra flakes present on all recent merged PRs ( Classification: Bug fix (infinite hang in Test proof:
Diff: Fix correctly addresses root cause — locked body streams were never piped to the destination blob. No TODOs/FIXMEs in added lines. O_TRUNC added to Bot threads: 6/6 resolved (coderabbit nitpicks addressed, claude[bot] findings triaged — pre-existing limitations noted, not regressions). Reviewer requested: @cirospaciari Awaiting human review to merge. |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@test/regression/issue/13237.test.ts`:
- Around line 67-95: In the "Bun.write with Response overwrites file completely"
test, capture and assert the return values from the two Bun.write calls (the
first call that writes 1000 bytes and the second that writes 100 bytes) to
ensure the function returns the number of bytes written; assign their results to
variables (e.g., write1, write2) and add expectations like
expect(write1).toBe(1000) and expect(write2).toBe(100) alongside the existing
file-content and length assertions on result from Bun.file(outFile).text(); this
uses the existing symbols Bun.write, outFile, and result to lock in return-value
semantics.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 8d0469db-ffb0-412c-96b5-721f9c599451
📒 Files selected for processing (1)
test/regression/issue/13237.test.ts
|
@robobun crashes on windows in ci |
|
🔍 Verification in progress — head Gate 1 (CI): 58/62 checks still pending (0 failures, 2 success, 1 neutral, 1 skipped). Waiting for CI to finish. ⏳ Waiting for CI to complete before final verdict. |
|
⏳ CI still running (58/62 checks pending, Lint JS ✅, Format ✅). No unresolved review threads. No new pushes on |
|
❌ Waiting for fixer push — head Gate 1 (CI): ❌ Build #39713 — 3 Windows failures in ⏳ Waiting for fixer to push a fix for the Windows assertion failure. Will re-check all gates when new commit lands. |
When writing a locked Response or Request body that already has an available ReadableStream (e.g. `new Response(req.body)`), pipe it directly to the file instead of waiting for `onReceiveValue` which never fires because there is no entity that will call `resolve()`. Also fixes: - Windows fd conversion via makeLibUVOwnedForSyscall for open syscall - Assertion failure when readStreamIntoSink completes synchronously - Return actual bytes written instead of hardcoded 0 - Memory leak in reject handler (deinit vs deref) Closes #13237
Address CodeRabbit review feedback by verifying that Bun.write returns the correct number of bytes written, not just that the file contents are correct.
pipeReadableStreamToBlob opened files without O_TRUNC, so overwriting a longer file with shorter content left stale trailing bytes — silent data corruption. - Windows path in Blob.zig: add bun.O.TRUNC to the open flags - Non-Windows path: fix FileSink.Options.flags() to respect the truncate field instead of ignoring it (was dead code: `_ = this;`) - Add regression test: write 1000 bytes then overwrite with 100 bytes, verify file contains only the 100 bytes
The overwrite test was using string-bodied Responses which go through the synchronous write path (already had O_TRUNC). Switch to ReadableStream-backed Responses so the test exercises the pipeReadableStreamToBlob code path where the O_TRUNC fix was applied.
robobun
force-pushed
the
claude/fix-bun-write-response-body-hang-v2
branch
from
924fb9d to
d627ffc
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/bun.js/webcore/Blob.zig`:
- Around line 1416-1429: The fast-path that handles locked-body readable streams
(the branch using response.getBodyReadableStream and bodyValue.Locked.readable)
currently calls destination_blob.pipeReadableStreamToBlob(...) passing only
options.extra_options which drops important file-creation semantics
(createPath/mkdirp_if_not_exists and options.mode); update this path to forward
the full WriteFileOptions (the same structure used by
WriteFileWaitFromLockedValueTask) into pipeReadableStreamToBlob, or, if
pipeReadableStreamToBlob cannot accept WriteFileOptions, call the existing
WriteFileWaitFromLockedValueTask path instead so that
createPath/mkdirp_if_not_exists and mode are preserved; ensure you reference and
thread WriteFileOptions, mkdirp_if_not_exists, options.mode,
destination_blob.pipeReadableStreamToBlob, and WriteFileWaitFromLockedValueTask
when making the change.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: e75e0a2d-b07d-4759-a494-892f589a2811
📒 Files selected for processing (3)
src/bun.js/webcore/Blob.zigsrc/bun.js/webcore/FileSink.zigtest/regression/issue/13237.test.ts
|
⏳ CI still running (61 checks pending, 2 passed) on |
3 participants
Summary
When
Bun.writereceives anew Response(req.body)(a locked body with an available ReadableStream), it waited foronReceiveValuewhich never fires — causing an infinite hang. This fix detects when the body already has a readable stream and pipes it directly to the file.Additional fixes in this PR:
makeLibUVOwnedForSyscallto convert the fd frombun.sys.opento a libuv-owned fd, fixing an assertion crash on Windowsbun.assert(!signal.isDead())which fires whenreadStreamIntoSinkcompletes synchronously (stream fully consumed viasink.end()without$startDirectStreambeing called)file_sink.writteninstead of hardcoded0deinit()instead ofsink.deref()in the reject handler to properly clean up all resourcesO_TRUNCflag so overwriting a file via Response stream replaces content completelyRoot Cause
In
Blob.writeFileInternal, when the source is aResponseorRequestwith a.Lockedbody value, the code registered aWriteFileWaitFromLockedValueTaskcallback ononReceiveValue. But fornew Response(req.body), the body is already locked with a readable stream available — no entity will ever callresolve()to triggeronReceiveValue, soBun.writehangs forever.Test Plan
test/regression/issue/13237.test.ts— 4 test cases covering:Bun.write(file, new Response(req.body))in a server handlerBun.write(file, new Response(readableStream))standaloneBun.write(file, new Response(req.body))after accessingreq.bodyUSE_SYSTEM_BUN=1→ 4 fail (timeout),bun bd test→ 4 passCloses #13237
Verification (d627ffc): CI green — all individual test shards passed (darwin-14-x64 and windows-11-aarch64 passed on retry, all 20 ASAN shards passed). Test proof confirmed: baked binary (main) 4/4 timeout FAIL; PR binary 4/4 PASS (3.29s). No unresolved review threads. No TODO/FIXME in diff. Ready for human review.