[robobun]

Problem

• An onLoad plugin that calls args.defer() but answers without awaiting it takes Bun.build down. Debug build: panic: int cast: TryFromIntError(NegOverflow) in BundleV2::on_parse_task_complete; depending on timing it is instead panic: internal error: entered unreachable code in BundleV2::on_load, a hang (what the released build mostly does), or ASAN heap-use-after-free in DeferredBatchTask::run_on_js_thread.
• defer() parks the load's unit of the scan counter, and an answer that arrived while it was parked did not take it back, so the load was counted twice. The counter then no longer described the in-flight work: underflow, hang, or linking starting while a parse was still writing. On the dev server this showed as other loads' defer() promises resolving before the answer's own imports were loaded.
• On the Bun.build thread the defer() notification and the answer were queued on the same intrusive queue node, so queuing the second rewrote the first: a lost notification, a dropped neighbouring task, or one node run twice.
• The task that resolves the defer() promises lived inside the BundleV2 and walked back to it when run. Without an await the build can finish and free the BundleV2 while that task is still queued; whether the promises ever settled depended on the same timing.

Fix

• An answer for a load whose unit is still parked moves the unit back first, and a defer() notification for a load that was already answered is ignored (docs: state the onLoad defer() lifetime and the error a stale call throws #37729 makes that call throw on the JS side). Property to check: every load puts exactly one unit through the counter, whatever the order of its two messages.
• The defer() notification gets its own queue node, so a load's two messages cannot overwrite each other, and both use the same queue, so they arrive in the order issued.
• The promise-resolving task is a small heap allocation holding only the plugin handle, which outlives it, so it never touches the build. Promises still unsettled when the build is complete are resolved at completion, on both Bun.build and the dev server; never rejected, since nobody may be awaiting them.
• Verification: new subprocess tests fail without the fix (NegOverflow panic or hang; the use-after-free in 3 of 3 ASAN runs; the early resume on both arms) and pass with it on the debug ASAN build. One remaining window from the original, a drain still queued when the bake CLI tears its plugin down, is unchanged in kind.

Background

• The scan counter (Graph::pending_items) counts outstanding loads, resolves and parses; when it reaches zero the scan is over and linking starts, so a counter that is too low starts linking while workers still write into the graph. Each outstanding onLoad request holds one unit, and its answer hands the unit to the parse it schedules.
• args.defer() lets an onLoad callback wait until every other module has been loaded. It moves the load's unit into Graph::deferred_pending; when pending_items hits zero the parked units move back and a task posted to the JS thread resolves the promises.
• The bundler has two arms. Bun.build runs the bundle on its own thread with a Mini event loop, and plugin callbacks post messages back to it through queue nodes embedded in each Load; the dev server (bake) runs the bundle on the JS thread itself, so the same messages travel through the JS loop.
• Plugin handle lifetime: for Bun.build the plugin object is destroyed by the completion task, posted to the same JS queue after the drain; the dev server keeps its plugin for its own lifetime. That is what lets the drain task hold only the handle.

Original description

What does this PR do?

An onLoad plugin that calls args.defer() but answers without waiting for the promise takes Bun.build down. Debug build:

panic: int cast: TryFromIntError(NegOverflow)
    BundleV2::on_parse_task_complete   src/bundler/bundle_v2.rs
    parse_worker::on_complete_mini <- MiniEventLoop::tick_once <- BundleV2::wait_for_parse

Depending on timing the same script instead dies with panic: internal error: entered unreachable code in BundleV2::on_load, never finishes (what the released build mostly does), or, once the counters are right, reads a freed BundleV2 from the task that resolves the promise (ASAN: heap-use-after-free in DeferredBatchTask::run_on_js_thread). Repro:

for (let i = 0; i < 20; i++) {
  await Bun.build({
    entrypoints: ["./src/index.ts"], // imports ./a and ./b
    plugins: [{
      name: "defer-without-await",
      setup(build) {
        build.onLoad({ filter: /\.ts$/ }, args => {
          void args.defer(); // not awaited
          return { contents: "export const x = 1;", loader: "ts" };
        });
      },
    }],
  });
}

Cause

Every outstanding onLoad request holds one unit of Graph::pending_items. .defer() moves that unit into Graph::deferred_pending (on_notify_defer) and drain_deferred_tasks moves it back once the rest of the scan reaches zero; the answer then hands the unit to the parse task (or consumes it on the error paths). Three things went wrong when the answer arrived while the unit was still parked:

1. on_load did not know the unit was parked. It scheduled the parse anyway, whose completion decremented pending_items a second time for the same load. From there the counter no longer describes the in-flight work: it underflows (NegOverflow), or a later drain moves the parked unit back with nothing left to consume it (hang). Since pending_items == 0 is what lets wait_for_parse return and linking start, a counter that is too low can also start linking while a parse worker is still writing into the graph. On the dev server, which runs the bundle on the JS loop, the same mismatch showed up as an early drain: the defer() promise of a load that was genuinely waiting resolved before the misbehaving load's own imports had been loaded.

2. On the Bun.build thread the .defer() notification and the answer were queued on the same intrusive node, Load::task. Queuing a node that is still in the MPSC queue rewrites its callback and next link: the notification is replaced by the answer, some other queued task is dropped (hang), or the node runs twice and the second on_load hits the unreachable!() on an already consumed value.

3. DeferredBatchTask, the task posted to the JS thread to resolve the promises, was embedded in the BundleV2 and walked back to it when run. With a proper await that is fine: the pass cannot finish until the resumed callbacks answer, which happens after the task ran. Without one, the answer is already queued when the drain is scheduled, so the pass finishes and init_and_run drops the Box<BundleV2> while the task is still queued behind whatever the JS thread is doing; the task then reads the freed pass. Whether the promise ever settled depended on the same timing (in a probe, all promises of a build settled in 3 to 8 percent of builds, none otherwise; on serve the shared plugin handed them to the next build's drain).

The Load::deferred flag that records where a load's unit lives (added in #37075 for cancellation) was also only set on the Bun.build arm; the dev server arm posted the notification without the load.

Fix

• on_load takes the unit back (deferred_pending -= 1, increment_scan_counter()) when the load is still deferred, so the answer is accounted for like any other load's. fail_outstanding_plugin_requests no longer needs its own handling of parked loads and routes them through on_load (the only difference is a cancellation message per parked load in a log a cancelled build never reports).
• on_notify_defer takes the load on both arms, sets the flag, and does nothing for a load that has already been answered (no longer in outstanding_loads, OutstandingLink::is_linked). Both notifications travel through the same queue as the answer, so the check is exact. Calling defer() after answering is a misuse; docs: state the onLoad defer() lifetime and the error a stale call throws #37729 makes the JS side throw for it, and this check is what keeps a call that does reach the bundler from corrupting the counters.
• The notification gets its own node, Load::defer_task (called_defer already limits it to one enqueue); the answer keeps Load::task. The post-to-the-owning-loop dispatch that on_load_async and on_resolve_async each spelled out is one helper, post_to_own_loop, which the new on_defer_async uses too; JSBundler::on_defer just calls it.
• DeferredBatchTask is now a small heap allocation holding only the plugin handle, created per drain (Task::from_boxed style: the dispatch arm consumes the box, release_unrun frees it at VM teardown, schedule frees it if the post is refused, which enqueue_on_js_loop_for_plugins now reports). It never touches the pass. The handle outlives it: for Bun.build the plugin is destroyed by the completion task, which is posted to the same queue after the drain; bake's plugins live as long as the dev server. The actual drain call moves to the runtime (PluginJscExt::drain_deferred, which does the exception-scope check the dispatch arm used to do), so the bundler no longer declares that FFI entry point.
• Promises still unsettled when the build is complete are resolved from JSBundleCompletionTask::on_complete (Bun.build, including the serve HTML routes that share a plugin) and from the dev server's finalize_bundle_cleanup, so a defer() that was not awaited settles exactly once the build is done, which is what the docs promise. They are always resolved, never rejected: rejecting a promise nobody awaited would surface as an unhandled rejection in the user's process. The mid-scan drain could never reject either (the completion's result is not set until after the scan), so drainDeferred's rejected parameter and the result_is_err vtable entry that fed it are removed.

Residual, unchanged in kind from before: the production bake CLI also drives the Js arm, and a drain scheduled by a misbehaving plugin that then fails its load could in principle still be queued when that command tears its plugin down. Before this change the same task would have read the freed pass instead.

How did you verify your code works?

test/bundler/bundler_defer.test.ts, describe("defer() that is not awaited"), each case spawning a script because the failures take the process down:

• before answering, 4 builds of 24 modules whose onLoad all call defer() without awaiting it: the bundle contains exactly the plugin-provided modules (the on-disk files throw) and every promise has settled by the time Bun.build resolves. Unfixed: the NegOverflow panic (or a hang, or unsettled promises, depending on timing).
• before answering with a gap before the answer and a busy JS thread afterwards, so the drain is scheduled and then the build finishes while it is still queued. Unfixed (with only the counter fix as well): ASAN heap-use-after-free in DeferredBatchTask::run_on_js_thread, 3 of 3 runs; the windows are wide enough that it still fired on a heavily loaded machine.
• after answering: x awaits defer(), y answers synchronously and calls defer() from a microtask (in a try/catch, since docs: state the onLoad defer() lifetime and the error a stale call throws #37729 makes that call throw), y's answer imports z; z is loaded before x resumes. Unfixed: hang (node collision) or x resuming early.
• cancelling the build (worker.terminate()) while one load is parked in defer() and another is unanswered. Passes before and after; it guards the fail_outstanding_plugin_requests change.

test/bake/dev/plugins.test.ts covers the dev server arm: the after-answering case (unfixed: x resumes before z is loaded), and a load that answers without awaiting defer() whose promise must settle only after the module its own answer imports has been loaded (unfixed: resolved as soon as the scan momentarily looked empty, reported as false by the route). The second case orders w's answer after x's defer() so the scan is never empty at that moment; otherwise resolving immediately would be correct.

With the fix: bundler_defer.test.ts (14), bake/dev/plugins.test.ts (5), bundler_plugin.test.ts (53), bundler_plugin_chain.test.ts (13), the counted family of worker-terminate-funnels.test.ts (the cancelled Bun.build case) and test/internal/source-lints pass on the debug (ASAN) build; cargo fmt, cargo clippy -p bun_bundler -p bun_runtime and clang-format are clean. With src/ reverted to the merge base, the two before-answering cases and both bake cases fail as described above.

Overlap with open PRs: #37709 touches DeferredBatchTask and the drain_deferred_tasks call to stop the old task from forming &mut BundleV2; this PR removes that walk-back altogether, so whichever lands second drops that part. #37729 adds the JS-side guard and its own tests to bundler_defer.test.ts; the tests here already tolerate it.

[coderabbitai]

Warning

Review limit reached

@robobun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 7 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: d7940b74-2aca-438b-a686-c322831e0492

📥 Commits

Reviewing files that changed from the base of the PR and between f59f705 and 365aff8.

📒 Files selected for processing (10)

• src/bundler/DeferredBatchTask.rs
• src/bundler/Graph.rs
• src/bundler/bundle_v2.rs
• src/jsc/bindings/JSBundlerPlugin.cpp
• src/runtime/api/JSBundler.rs
• src/runtime/api/js_bundle_completion_task.rs
• src/runtime/bake/DevServer.rs
• src/runtime/dispatch.rs
• test/bake/dev/plugins.test.ts
• test/bundler/bundler_defer.test.ts

---

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

[robobun]

Status

• Reproduced on the released build and on a debug build at 3c87727 with the script in the description: panic: int cast: TryFromIntError(NegOverflow) in BundleV2::on_parse_task_complete, alternating with entered unreachable code in BundleV2::on_load and hangs, depending on timing. Self-review then turned up the third part: with the counters fixed, the mid-scan drain task could still run after the build had freed its BundleV2 (ASAN heap-use-after-free), and whether an unawaited promise settled at all was timing-dependent. 757026e fixes both; see the description.
• Tests: test/bundler/bundler_defer.test.ts (4 new cases) and test/bake/dev/plugins.test.ts (2 new cases). With src/ reverted to the merge base, the two before-answering cases and both bake cases fail (panic / ASAN report / early resolution); everything passes with the fix on the debug (ASAN) build.
• Review threads are all answered and resolved.
• CI: build 93063 (the previous revision) had 192 of 194 jobs green; the two darwin-26 aarch64 test lanes never got an agent and expired, after the one retrigger I will push. Build 93386 (current revision) is failing in the vendored lolhtml download step, which hit every build in that window (93380 through 93388); the failed build lanes need a Buildkite retry, nothing in the diff is involved.

[robobun]

^{Updated 3:05 PM PT - Aug 12th, 2026}

❌ @robobun, your commit 365aff8 has 1 failures in Build #93386 (All Failures):

• scripts/build/ci.ts - build failed on 🐧 x64 - build-bun
• scripts/build/ci.ts - build failed on 🐧 x64-musl - build-bun
• scripts/build/ci.ts - build failed on 🐧 aarch64-android - build-bun

---

🧪   To try this PR locally:

bunx bun-pr 37731

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

bun-37731 --bun

[robobun]

Pushed 7b9bd4e (the cancellation fixture rejects on the worker's error event and exits non-zero if the build settles before it is armed, so a broken precondition reports itself instead of timing out) and 8ac83ee (comment trim). The remaining comments are one or two lines each plus the # Safety section on post_to_own_loop; the threads are answered and resolved. No code change since e3571ed.

[claude]

Thanks for wiring the worker "error" handler in the cancellation fixture — that addresses my earlier note. I re-reviewed after 8ac83ee and didn't find any bugs; because this reworks cross-thread scan-counter bookkeeping and intrusive queue-node ownership in bundle_v2.rs (new unsafe fn post_to_own_loop, second defer_task node, the FIFO-ordering assumption behind the is_linked() check), a maintainer look is still worthwhile.

What was reviewed:

• on_load's new deferred branch balances against on_notify_defer on both the Mini and JS-loop arms, and fail_outstanding_plugin_requests now routing deferred loads through on_load reaches the same net counter state as the removed special case.
• post_to_own_loop is a mechanical dedup of the previous on_load_async/on_resolve_async bodies; on_defer_async uses the separate defer_task offset so it cannot re-enqueue the answer's node.
• on_defer reads self.bv2 into a local before posting, so append_defer_promise (Plugin-only) does not touch the Load after the owning loop may have it.
• The three new subprocess tests assert the strongest observable (bundle output / event ordering / clean terminate), fail-fast on unexpected build settlement, and cover both loop arms plus cancellation.

Extended reasoning...

Overview

Fixes a scan-counter imbalance in BundleV2 when an onLoad plugin calls args.defer() without awaiting it, which panicked (NegOverflow / unreachable) or hung Bun.build. Touches src/bundler/Graph.rs (adds OutstandingLink::is_linked), src/bundler/bundle_v2.rs (adds Load::defer_task, reworks on_notify_defer to take the Load and ignore late notifications, has on_load reclaim a still-parked unit, extracts post_to_own_loop, simplifies fail_outstanding_plugin_requests), and src/runtime/api/JSBundler.rs (on_defer now delegates to on_defer_async; ~45 lines of hand-rolled loop dispatch removed). Tests added to bundler_defer.test.ts (three subprocess cases) and bake/dev/plugins.test.ts (JS-loop arm).

Security risks

None. No untrusted-input parsing, no auth/crypto/permissions surface. The change is internal bundler bookkeeping.

Level of scrutiny

High. This is concurrency-sensitive native code in the bundler core: pending_items == 0 is what lets wait_for_parse return and linking begin, so a mis-counted unit can start linking while a parse worker is still writing into the graph (a data race, not just a hang). The fix also introduces a second intrusive MPSC queue node on Load and a new unsafe fn post_to_own_loop whose safety contract ("not queued anywhere else, and *request outlives the hop") is discharged by callers via called_defer / arena ownership. The correctness of the is_linked() late-defer check relies on FIFO delivery of the shared queue between the defer notification and the answer. These are exactly the invariants REVIEW.md flags under "Know the thread affinity of every line you touch" and "Never let a pointer or slice outlive the memory it points into".

Other factors

The PR is well-tested: three new subprocess-spawned cases (before-answer, after-answer, cancelled-while-parked) plus a dev-server case for the JS-loop arm, each verified by the author to fail on the unfixed build. My prior feedback (wiring the worker error event so a pre-arm failure surfaces instead of timing out) was addressed in 7b9bd4e, and the comment-cop verbosity flags were trimmed in 8ac83ee. The post_to_own_loop extraction is a straight dedup of the two existing bodies with the task-field offset parameterised. I checked that fail_outstanding_plugin_requests popping (which clears linked) followed by on_load's unlink (no-op on unlinked) then the deferred branch reaches the same counter state as the removed special case, and that on_defer reading bv2 before posting keeps the post-posting append_defer_promise call from touching the Load. No issues found, but the thread-affinity and queue-ordering reasoning is subtle enough that a maintainer familiar with the Mini-loop MPSC semantics should confirm it.

[claude]

I re-reviewed after 7b9bd4e (which addressed the earlier note about wiring the worker error event) and 8ac83ee; no bugs found this pass. This is a scan-counter accounting fix in the bundler's cross-thread plugin plumbing — new intrusive queue node, an unsafe fn post_to_own_loop helper, and reworked on_notify_defer/on_load bookkeeping — so a human look at the counter/queue-node invariants would still be worthwhile.

What was reviewed:

• on_load's new deferred branch and the removed special case in fail_outstanding_plugin_requests — the parked unit is moved back exactly once on both the answer and cancel paths.
• post_to_own_loop against the two prior open-coded copies — behavior-preserving; defer_task is a distinct node so the answer and the notify no longer share Load::task.
• The is_linked() guard in on_notify_defer — both hops (Mini and JS) go through the same queue as the answer, so the ordering the guard relies on holds.
• The three new bundler_defer.test.ts cases and the bake case — each asserts observable output (bundle contents / event ordering / terminated), not just absence-of-crash.

Extended reasoning...

Overview

Fixes a scan-counter double-decrement / intrusive-queue-node reuse bug when an onLoad plugin calls args.defer() without awaiting it. Touches src/bundler/bundle_v2.rs (adds Load::defer_task, extracts unsafe fn post_to_own_loop, adds on_defer_async, reworks on_notify_defer to take the Load and check is_linked(), moves the parked unit back in on_load, drops the parked-load special case from fail_outstanding_plugin_requests), src/bundler/Graph.rs (adds OutstandingLink::is_linked), and src/runtime/api/JSBundler.rs (deletes on_notify_defer_raw/on_notify_defer_mini_wrap and the hand-rolled loop dispatch in on_defer, now a three-liner). Tests: three new subprocess cases in test/bundler/bundler_defer.test.ts and one dev-server case in test/bake/dev/plugins.test.ts.

Security risks

None. No untrusted-input parsing, auth, or crypto surface; the change is internal bundler bookkeeping.

Level of scrutiny

High. pending_items == 0 is what lets wait_for_parse return and linking begin; miscounting here either hangs or starts linking while a parse worker is still writing into the graph. The fix also introduces a second intrusive MPSC queue node on Load and a new unsafe fn that generalizes the cross-thread hop, both of which carry lifetime/aliasing obligations spelled out in the # Safety doc. The refactor of on_load_async/on_resolve_async into the shared helper is behavior-preserving as far as I can tell (same Posted::Refused handling, same enqueue_task_concurrent_with_extra_ctx shape), but it is a refactor of a hot cross-thread path.

Other factors

My earlier inline note (wire the worker error event and fail fast if the build settles early) was applied in 7b9bd4e; the comment-cop threads were resolved by 8ac83ee and the remaining comments are one/two lines plus the required # Safety block. The PR description states the new tests fail with src/ reverted and pass with the fix on the ASAN debug build, and lists the sibling suites that were run. All review threads are resolved. Given the concurrency-sensitive nature of the counter/queue-node changes I'm deferring rather than approving.

[robobun]

Heads up on an overlap with #37729, which makes a kept args.defer throw (Can't call .defer() after the onLoad plugin has finished) once the load it belongs to has been answered, on every path, because after the answer the Load it points at is consumed and later freed with the build.

That affects the two "after answering" tests here (the Bun.build one in bundler_defer.test.ts and the dev server one in test/bake/dev/plugins.test.ts): the defer() that y calls from a microtask after answering becomes an uncaught error with #37729 applied, so toSpawn("ok") fails on exit code and stderr, and the dev server request fails the same way. With both PRs in, the is_linked() early return in on_notify_defer is no longer reachable from JS, since a notification can only be issued before the answer and it travels the same queue as the answer. The rest of this PR (the accounting when defer() is called before answering and not awaited, and the separate defer_task node) is independent of #37729 and still needed.

Whichever of the two lands second will need to drop or rewrite those two tests (the post-answer behaviour is covered by #37729's tests), and both PRs append to the end of bundler_defer.test.ts, so there is a small textual conflict either way.

[robobun]

Pushed 757026e and 365aff8. Self-review of the first revision found that the task resolving the defer() promises mid-scan (DeferredBatchTask) was embedded in the BundleV2 and could run after a build whose plugin had answered without awaiting had already freed it (ASAN heap-use-after-free, reproducible with a busy JS thread), and that whether such a promise ever settled was timing-dependent. The task is now a small heap allocation holding only the plugin handle, leftover promises are resolved when the build completes (Bun.build completion and the dev server's bundle cleanup), and the always-false rejected path is gone. The description is rewritten to match; the late-defer tests now tolerate #37729 making that call throw, and the dev server arm of the take-back has a test. Also reported separately: a pre-existing dev-server crash when an onLoad plugin throws (the bundle arena is freed inside on_load), which the review tripped over and which this PR does not touch.

[robobun]

Re the #37729 overlap: as of 365aff8 both "after answering" tests wrap the late defer() in a try/catch, so they pass with or without #37729 applied, and the description now calls that call a misuse that #37729 rejects. The is_linked() return stays as the bundle thread's own guard for a notification that does arrive late; until #37729 lands it is also what those two tests exercise. Whichever PR lands second should only have the append conflict at the end of bundler_defer.test.ts to resolve.

[claude]

I reviewed the changes since my last pass (7b9bd4e addressed the fixture error-wiring; 757026e redesigned DeferredBatchTask to be heap-allocated and added drain_deferred() at build completion; 365aff8 widened the drain-race test window) and didn't find bugs. Given the cross-thread lifetime reasoning in the DeferredBatchTask rewrite and the new unsafe fn post_to_own_loop, a human look is still worthwhile.

What was reviewed:

• DeferredBatchTask now carries only NonNull<JSBundlerPlugin>; checked the ordering claim that the plugin handle outlives the queued task (Bun.build: completion task posts to the same queue after; bake: dev-server-lifetime plugin).
• on_load reclaiming the parked unit before scheduling parse; fail_outstanding_plugin_requests now routes deferred loads through on_load — traced that on_load's guard drops the path/namespace on the error arm.
• on_notify_defer's is_linked() early-return relies on defer-notify and answer sharing the same queue; verified both arms of post_to_own_loop post to the same target as on_load_async.
• JSBundlerPlugin__drainDeferred losing the rejected param — the only caller that passed true was the removed result_is_err path; new callers (completion, bake cleanup) always want resolve.

Extended reasoning...

Overview

The PR fixes scan-counter underflow/hang when an onLoad plugin calls .defer() without awaiting it. It touches src/bundler/{bundle_v2,Graph,DeferredBatchTask}.rs, src/runtime/api/{JSBundler,js_bundle_completion_task}.rs, src/runtime/bake/DevServer.rs, src/runtime/dispatch.rs, src/jsc/bindings/JSBundlerPlugin.cpp, plus tests in test/bundler/bundler_defer.test.ts and test/bake/dev/plugins.test.ts. Since my previous review, 757026e rewrote DeferredBatchTask from an intrusive BundleV2 field to a heap-allocated task carrying only the plugin handle, and added drain_deferred() at build completion on both the Bun.build and dev-server paths.

Security risks

None identified. This is internal bundler bookkeeping; no user-controlled input reaches new parsing or path handling.

Level of scrutiny

High. The change reasons about cross-thread task lifetimes (the drain task can outlive its BundleV2; the plugin handle it carries must not be destroyed until after the task runs or is released), adds a second intrusive queue node (Load::defer_task) to avoid re-enqueueing the same node, and introduces unsafe fn post_to_own_loop that takes a caller-supplied field offset. pending_items == 0 gates linking, so an accounting error here can start linking while a parse worker is still writing into the graph. This is exactly the class of change REVIEW.md flags for careful human review (intrusive nodes, cross-thread refcounts, "who frees this, when, on which paths").

Other factors

• My earlier feedback (wire the worker error event in the cancellation fixture) was addressed in 7b9bd4e.
• The author noted an overlap with #37729 that will require rewriting the two "after answering" tests when whichever lands second — a merge-order coordination point a human should be aware of.
• The seven open comment-cop bot flags on the latest commit target module/doc comments and # Safety sections; they look like heuristic noise rather than substantive feedback, but they're technically unresolved.
• Test coverage is thorough (four new subprocess-spawned cases plus two dev-server cases), and the PR description states they fail with src/ reverted.

[Jarred-Sumner]

This is Claude (an AI assistant) commenting on Jarred's behalf.

While putting #46021 together we checked this against main, and the crash it fixes no longer happens there. Closing. Please reopen it if that's wrong.