Clone fetch response buffer to main thread heap for proper GC reclamation

[robobun]

Problem

Fetch response body memory is never returned to the OS after GC collects the Blob/Response objects (#28741, #12941, #28427).

Reproduction:

let blobs = [];
for (let i = 0; i < 30; i++) {
  const res = await fetch(url);
  blobs.push(await res.blob());
}
blobs = [];
Bun.gc(true); // Memory NOT freed — 0% released

Node.js releases ~73% of memory in the same scenario; Bun released 0%.

Root Cause

FetchTasklet.callback() runs on the HTTP thread, where it appends response data to scheduled_response_buffer via write(). This allocates the buffer on the HTTP thread's mimalloc heap.

When the body is later consumed and GC finalizes the Blob, Store.deref() → Bytes.deinit() calls mi_free() on the main JS thread. In mimalloc, cross-thread frees go to the allocating thread's delayed-free list. Since the HTTP thread is idle after fetches complete, it never processes that list — so the pages are never returned to the OS.

Manual new Blob([data]) works fine because the data is allocated on the main thread from the start.

Fix

In cloneResponseBufferToMainThread(), when transferring the response buffer from FetchTasklet to the body value (which always happens on the main thread in onBodyReceived/toBodyValue), clone the data into a fresh main-thread allocation. The old HTTP-thread buffer is freed immediately.

Verification

	Before	After
System bun (30×1MB fetch→blob→GC)	0.0% released	—
Debug build (same test)	—	28.5% released

The test spawns a local server, fetches 30×1MB blobs, drops all references, forces GC, and asserts >20% memory is reclaimed. Passes with the fix, fails on system bun.

Closes #28741

[claude]

⚠️ Code review skipped — your organization's overage spend limit has been reached.

Code review is billed via overage credits. To resume reviews, an organization admin can raise the monthly limit at claude.ai/admin-settings/claude-code.

Once credits are available, push a new commit or reopen this pull request to trigger a review.

[robobun]

^{Updated 5:34 AM PT - Apr 1st, 2026}

❌ @autofix-ci[bot], your commit 8772e0b has 4 failures in Build #43090 (All Failures):

• test/js/bun/webview/webview.test.ts - timeout on 🍎 13 aarch64
• test/js/bun/webview/webview.test.ts - timeout on 🍎 14 aarch64
• test/js/bun/webview/webview.test.ts - timeout on 🍎 13 x64
• test/js/bun/webview/webview.test.ts - timeout on 🍎 14 x64
• test/js/third_party/@azure/service-bus/azure-service-bus.test.ts - SIGILL on 🐧 13 x64-asan
• test/js/bun/webview/webview-chrome.test.ts - code 1 on 🍎 13 aarch64
• test/regression/issue/28741.test.ts - code 1 on 🍎 13 aarch64 (new)
• test/regression/issue/28741.test.ts - code 1 on 🍎 14 aarch64 (new)
• test/regression/issue/28741.test.ts - code 1 on 🍎 14 x64 (new)
• test/regression/issue/28741.test.ts - code 1 on 🍎 13 x64 (new)

---

🧪   To try this PR locally:

bunx bun-pr 28743

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

bun-28743 --bun

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: ff4dc92d-7d33-424a-97a7-d17f0ba4eafc

📥 Commits

Reviewing files that changed from the base of the PR and between 3ed4186 and 8772e0b.

📒 Files selected for processing (2)

• src/bun.js/webcore/fetch/FetchTasklet.zig
• test/regression/issue/28741.test.ts

---

Walkthrough

The changes modify fetch response body buffering in FetchTasklet.zig to use a dedicated cloneResponseBufferToMainThread() helper that duplicates buffered bytes on the main thread and resets the buffer, ensuring proper memory management. A regression test validates that fetch response body memory is reclaimed by garbage collection.

Changes

Cohort / File(s)	Summary
Fetch buffer cloning src/bun.js/webcore/fetch/FetchTasklet.zig	Added cloneResponseBufferToMainThread() helper to duplicate buffered response bytes on the main thread and reset the buffer. Updated buffering completion path and body value construction to use cloned byte list instead of directly transferring ownership of scheduled response buffer.
Memory GC regression test test/regression/issue/28741.test.ts	Added test that spawns a subprocess with an HTTP server returning 1MB buffers, performs multiple fetch requests, collects blobs, triggers garbage collection, and verifies that at least 20% of allocated memory is reclaimed.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main change: cloning fetch response buffer to main thread heap for GC reclamation, which is the core fix for the memory leak issue.
Description check	✅ Passed	The description comprehensively covers Problem, Root Cause, Fix, and Verification sections, exceeding the basic template requirements with detailed technical explanations and test results.
Linked Issues check	✅ Passed	The code changes (cloning response buffer on main thread and adding GC reclamation test) directly address issue #28741's requirement: memory allocated during fetches should be reclaimed by GC when references are removed.
Out of Scope Changes check	✅ Passed	All changes are scoped to addressing the fetch response buffer memory leak: the FetchTasklet buffer cloning implementation and corresponding regression test for GC memory reclamation.

_{✏️ 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.}