[robobun]

Fixes #44018, fixes #44020

Problem

• In a node:worker_threads Worker, an unhandled rejection from the callback that let the loop drain (timer, immediate, child 'exit', 'beforeExit') was dropped: no 'error' event, exit code 0. Node reports 'error' and exits 1.
• Cause: auto_tick_active (src/runtime/jsc_hooks.rs) runs those callbacks but, unlike auto_tick, ran no handleRejectedPromises. unhandled_rejection() set no exit code.
• An 'exit' listener that throws replaced the exit code with 1: process.exitCode = 4 exited 1 (node: 4).

Fix

• auto_tick_active ends with the rejection pass. dispatch_on_before_exit runs a microtask checkpoint and that pass after the listeners.
• fail_exit_code (src/jsc/VirtualMachine.rs) is the one place where a fatal error sets exit code 1. While 'exit' is emitted, the code in effect stands. With none chosen, the main thread exits 1 and a worker 0.
• A worker reports a throw from an 'exit' listener and stops at it.
• Verified: new cases in worker_threads.test.ts, process.test.js, repl.test.ts, each pinned against node 26.

Background

• The run loops are while alive { tick(); auto_tick_active(); }. A rejection from auto_tick_active waited for the next tick(). An idle loop has none.
• Considered a rejection pass in the worker's spin() only: the main thread has the same gap.

Downsides

• A worker or process that exited 0 after a dropped rejection now exits 1.
• Until bun run: decide the exit code of a printed error before 'exit' listeners run #38116 merges: after a printed Bun.serve handler error, process.exitCode = 0 and a throwing 'exit' listener, bun run exits 0 (main: 1).
• Per setImmediate turn: +2 instructions against the base branch (3,411 to 3,414, spread 5). Text: +256 bytes.

Notes

Stacked on #42031 (base branch robobun/ccb1615d/events-capture-rejections). That PR makes the rejection reporter run the ticks and microtasks of the listeners after each batch, and gives it an inlined check for a turn with no rejected promise. Once it merges, the base of this PR becomes main.

Worker matrix (worker body, events seen by the parent, exit code). Each of the 24 bodies tried gives the same events and exit code on this branch and on node 26:

door                              bun 1.4.2                  this branch = node 26
timer                             (no event)        exit 0   error:R            exit 1
queueMicrotask / nextTick tail    (no event)        exit 0   error:R            exit 1
beforeExit, beforeExit async      (no event)        exit 0   error:R            exit 1
child 'exit'                      (no event)        exit 0   error:R            exit 1
Bun.sleep().then, setImmediate    (no event)        exit 0   error:R            exit 1
kept alive (setInterval)          error:R           exit 0   error:R            exit 1
'exit' listener sees              exit:0:undefined  exit 0   exit:1:1           exit 1
own unhandledRejection listener   (no event)        exit 0   message:UR:x       exit 0
'exit' listener throws            (no event)        exit 0   error:T            exit 0
same, under process.exit(4)       error:T           exit 1   error:T            exit 4
same, bare process.exit()         error:T           exit 1   error:T            exit 0
same, two listeners               first, second     exit 0   first, error:T     exit 0

Main thread, an 'exit' listener that throws (exit status):

script                                            main   this branch = node 26
process.exitCode = 4                              1      4
process.exitCode = 0                              1      0
no exit code                                      1      1
the listener sets process.exitCode = 9            1      9
process.exit(7)                                   1      7
process.exit(0)                                   1      0
process.exit()                                    1      1
process.exitCode = 4, then process.exit()         1      4
after an unhandled rejection, listener sets 98    1      98
after an uncaught exception                       1      1
process.exit() after a reported rejection, no throw   0  1

bun repl: a session reports its errors and goes on, so they do not decide its exit code (process.exitCode, or 0, as in node's REPL). bun 1.4.2 exited 1 after an uncaught exception in a session and 0 after a rejection. bun repl -e is not a session and exits 1.

The case in Downsides: bun run stores exit code 1 for a printed error after the 'exit' listeners ran (the tail of Run::start). A throw from an 'exit' listener leaves through process_exit and never reaches that store. main passed a literal 1 there. This branch passes the code in effect, which the program set to 0. #38116 stores the 1 before the 'exit' listeners run, and then the code in effect is 1. The two PRs merge with no conflict.

Known differences that remain, unchanged by this PR:

• When a rejection ends a worker, bun posts 'error' before it runs the worker's 'exit' listeners. A message posted from an 'exit' listener arrives after 'error' (node: before).
• On the main thread, process.exit(n) runs the 'exit' listeners registered after one that throws. Tracked as separate work.
• bun reports rejections at the end of a loop phase, node after each callback. If the callback that rejects and the callback that calls process.exit() are due in the same turn, the process exits before the report.
• Inside bun test, a worker's uncaught error is taken by the test runner. worker_threads: run worker uncaughtException/unhandledRejection listeners under bun test #36445 covers it.
• A worker with a pending top-level await and process.exitCode = 0 exits 13. node 26 does the same.

Measurements. Release builds of main (36cd151), the base branch (b005757) and this branch (f8b6c33) on the same machine. Sections from size. Instructions are user-space instructions of the main thread for one operation, counted exactly by single-stepping with ptrace between two marker system calls, as the difference of a run with 500 and a run with 1,500 operations. BUN_JSC_useJIT=0, one GC marker and no concurrent GC make the count repeatable: the spread between two runs is 5 instructions or less. perf (perf_event_open is not permitted), valgrind, strace and bloaty are not available on the build machine.

operation                               main      base branch   this branch
setImmediate turn                       3,436     3,411         3,414
setTimeout(0) turn                      5,236     5,204         5,206
rejection handled late, one per turn    6,387     6,355         6,361
rejection taken by a listener           6,548     6,792         6,765
text section, bytes                     80,661,004  80,660,702  80,660,958

An earlier head of this branch (ed96331) measured 3,495 per setImmediate turn by the same method. The reporter made two calls per pass then. It is one inlined load and compare now.

Suites run locally (Linux x64 debug+ASAN): test/js/node/worker_threads/ (all files), test/js/web/workers/worker.test.ts, process.test.js, event-emitter.test.ts, repl.test.ts, and a sweep of node's test-process-*, test-promise*, test-timers-*, test-worker-*, test-events*, test-stream-* tests with no result change.

Closed PRs that each addressed one face of this, superseded by this one: #37981, #34193, #32866. #40132 changes the signature of WebWorker::exit(). The PR that lands second needs a small rebase.

---

no test proof · iteration 10 · platform-specific test(s) that do not run on this machine, deferring to CI, which covers all platforms: test/js/node/process/process.test.js, test/js/bun/repl/repl.test.ts

[robobun]

^{Updated 7:27 AM PT - Sep 26th, 2026}

❌ @robobun, your commit b005757 has 2 failures in Build #120961 (All Failures):

• test/js/bun/spawn/spawn.test.ts - code 1: stdout reader of an unref'd child and process lifetime > an idle reader stopped at the highwater … on 🐧 13 x64-asan
• test/js/bun/s3/s3.test.ts - code 1 on 🐧 13 x64-asan
• test/js/bun/s3/s3.test.ts - code 1 on 🐧 13 x64
• test/js/bun/s3/s3.test.ts - code 1 on 🐧 25.04 x64
• test/js/bun/s3/s3.test.ts - code 1 on 🐧 3.23 x64

---

🧪   To try this PR locally:

bunx bun-pr 42032

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

bun-42032 --bun

[robobun]

Status: on hold as a draft. #45582 and #45575 cover part of this PR, and its base (#42031) is closed in favor of #45597. This comment lists what is covered and the 14 cases that remain. When #45582 and #45575 merge, I will rebase this PR onto main and cut it down to those cases.

#46758 depends on the rule that stays in this PR: a fatal error keeps the exit code in effect while 'exit' is emitted. The rebase will add the cases from its review, with the values of node 26.3.0:

• A rejection first, then an 'exit' listener that throws, with process.exitCode = 0 or 4: exit 1.
• process.exitCode = 5, then process.exitCode = undefined, then an 'exit' listener that throws: exit 1. This needs fix(process): allow clearing exitCode #42607.
• process.exit(3) from a 'beforeExit' listener, then an 'exit' listener that throws: exit 3.
• process.exitCode = 5 and a 'beforeExit' listener that throws: the 'exit' listeners get 1 and the process exits 1.

One of the remaining cases, reproduced on bun 1.4.2 and on main at 91e7e3b with #45575, #45582 and #45597 merged (Linux x64), compared with node 26.3.0:

process.exitCode = 4;
process.on("exit", () => {
  throw new Error("T");
});
// bun: exit status 1. node 26 and this branch: 4.

[claude]

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

• 🔴 src/jsc/VirtualMachine.rs — fail_exit_code() guards the two ordinary error paths (lines 1720, 3876) so a throw during 'exit' cannot overwrite process.exitCode, but the worker recursion-guard arm at line 1686 still writes self.exit_handler.exit_code = 1 unconditionally. With is_shutting_down = true no longer set before shutdown()'s on_exit(), a worker whose 'exit' listener throws while an uncaughtException listener also throws now reaches this line and reports exit code 1 instead of the user-chosen process.exitCode — the base branch returned early at the is_shutting_down() check and preserved it. Fix: route this write through fail_exit_code(global_object) so every unhandled-error exit_code = 1 respects process._exiting.

  Extended reasoning...

  Worker body: process.exitCode = 4; process.on('uncaughtException', () => { throw new Error('h'); }); process.on('exit', () => { throw new Error('T'); }); and let the loop drain. spin() → shutdown() → on_exit() (this PR removed the vm.is_shutting_down = true that used to precede it) → dispatch_on_exit(4) → dispatchExitInternal sets m_isExiting = true and emits 'exit'. The listener throws; innerInvokeEventListeners catches it and calls Bun__reportUnhandledError → uncaught_exception(T). On the base branch is_shutting_down() was true here and the function returned early, so exit_code stayed 4. On this branch it is false, so we proceed: is_handling_uncaught_exception = true, Bun__handleUncaughtException emits 'uncaughtException', that listener throws, innerInvokeEventListeners catches it and re-enters uncaught_exception. is_handling_uncaught_exception is true → the !is_main_thread() arm runs and writes self.exit_handler.exit_code = 1 with no Bun__Process__isExiting check. shutdown() then reads exit_handler.exit_code (now 1) into…

  Verification: normal — The PR applies its new fail_exit_code() guard (respect process._exiting) at two of the three sibling sites that write exit_handler.exit_code = 1, but leaves the worker recursion-guard arm at src/jsc/VirtualMachine.rs:1686 unconditional, and the PR itself makes that arm newly reachable during 'exit' dispatch. Trace of the failure scenario (worker sets process.exitCode = 4, has a…

• 🟣 src/jsc/VirtualMachine.rs — pre-existing: fail_exit_code()'s _exiting guard does not reach the main-thread exit_on_uncaught_exception arm — a throw from an 'exit' listener on a natural drain still calls (hooks.process_exit)(global, 1), whose first line is vm.exit_handler.exit_code = code, so process.exitCode = 4; process.on('exit', () => { throw new Error('T') }) exits 1 (Node: 4). The worker case is fixed because !is_main_thread() falls through to line 1720; the main thread does not. Fix: when Bun__Process__isExiting(global) is true, pass the current exit_handler.exit_code (not the literal 1) to process_exit, or skip this arm and fall through to fail_exit_code.

  Extended reasoning...

  Main thread, natural drain: Run::start → on_before_exit() (line 1556) → dispatch_on_before_exit → Process__dispatchOnBeforeExit (BunProcess.cpp:860) unconditionally calls Bun__VirtualMachine__exitDuringUncaughtException, so exit_on_uncaught_exception = true. Then on_exit() (run_command.rs:1570) → dispatch_on_exit → dispatchExitInternal sets m_isExiting = true and emits 'exit'; the listener throws → EventEmitter::innerInvokeEventListeners catches it → Bun__reportUnhandledError → uncaught_exception. is_shutting_down() is still false (set only at line 1837, after dispatch_on_exit), so line 1708 (exit_on_uncaught_exception && is_main_thread()) is taken and (hooks.process_exit)(global, 1) runs node::process::exit (node_process.rs:71) which does vm.exit_handler.exit_code = 1, discarding the user's process.exitCode = 4, then re-enters on_exit/global_exit and exits 1. Base behaves the same, so this is pre-existing; the PR's fail_exit_code guard (line 1720) and its doc comment ("Once 'exit' is being emitted the code is left alone") cover only…

  Verification: pre-existing. The main-thread exit_on_uncaught_exception arm bypasses the new _exiting guard and hardcodes exit code 1. Trace for process.exitCode = 4; process.on('exit', () => { throw new Error('T') }) on the main thread, natural drain: 1. process.exitCode = 4 → Bun__setExitCode → vm.exit_handler.exit_code = 4 (src/jsc/VirtualMachine.rs:676). 2. on_before_exit() →… | pre-existing —…

[robobun]

On the two findings outside the diff: the worker recursion-guard arm (a throw from an uncaughtException listener while 'exit' listeners run) now goes through fail_exit_code too, with a test row (process.exitCode = 4 plus throwing uncaughtException and exit listeners gives error:h, exit 4, as in Node). The main-thread exit_on_uncaught_exception arm (process.exitCode = 4 then a throwing 'exit' listener on a natural drain exits 1, Node: 4) is pre-existing and left for a follow-up: matching Node there also needs its "exit code was explicitly set" distinction, since the same case without process.exitCode exits 1 in Node.

[claude]

Thanks — fail_exit_code now queries self.global() instead of the reporting global, which addresses the node:vm-context concern I raised. I re-reviewed and didn't find further bugs; a human look is still worthwhile given this reorders is_shutting_down relative to user 'exit' listeners and adds rejection checkpoints to the shutdown-adjacent tick paths.

What was reviewed:

• worker.exit() replacing the manual terminate pair — it sets exit_called, set_requested_terminate(), and request_termination() on a still-live self.vm, so behavior is a superset of the old path.
• Dropping vm.is_shutting_down = true before vm.on_exit() in shutdown() — on_exit itself sets it after dispatch_on_exit, so the flag is still set before cleanup hooks; only the window during 'exit' listeners changed.
• Bun__Process__isExiting — guards on hasProcessObject() before dereferencing, and the Rust extern signature matches (&JSGlobalObject → Zig::GlobalObject*).
• New tests: events.sort() before comparison sidesteps the acknowledged error/message ordering divergence; expected arrays are already in sorted order.

Extended reasoning...

Overview

This PR closes a family of gaps where an unhandled rejection raised during a worker's (or the main thread's) final event-loop turn was silently dropped with exit code 0. It adds a handle_rejected_promises tail to auto_tick_active (both branches), a microtask+rejection drain after dispatch_on_before_exit, a new fail_exit_code() helper gated on process._exiting via a new C++ FFI export Bun__Process__isExiting, wires unhandled_rejection to set exit code 1, switches the worker error handler to worker.exit(), and defers is_shutting_down = true until after user 'exit' listeners run in the worker path. Tests land in the existing process.test.js and worker_threads.test.ts files as a test.concurrent.each matrix of 14 end-of-life scenarios plus two main-thread cases.

Security risks

None identified. The change is behavioral (exit-code and error-reporting fidelity) and does not touch auth, crypto, network parsing, or untrusted-input validation. The new FFI export reads a boolean field on a VM-owned object with a null-guard.

Level of scrutiny

High. This PR touches VM shutdown ordering, worker termination, and the event-loop tick tail — paths where a subtle regression manifests as hangs, double-teardown, or lost error reporting rather than a clean test failure. The is_shutting_down reordering and the let _ = discards on drain_microtasks/handle_rejected_promises results in shutdown paths are the kind of change where a maintainer familiar with the historical reasons for the prior ordering should confirm nothing depended on is_shutting_down being set before 'exit' listeners in the worker (I traced on_exit and it sets the flag itself after dispatch_on_exit, so the net effect looks correct, but the surrounding invariants are dense).

Other factors

My one prior inline finding — fail_exit_code passing a possibly-NodeVMGlobalObject reporting global to Bun__Process__isExiting — was addressed in the current revision: the helper now takes no argument and calls Bun__Process__isExiting(self.global()), with a comment noting exactly this. The test coverage is thorough (each row in the PR's door matrix maps to a .each case), tests follow harness conventions (subprocess with -e, Promise.all drain, combined-object assertion, test.concurrent.each), and the PR description records local runs across the affected Node parallel tests on Linux+ASAN and Windows. The PR is stacked on #42031 and notes it supersedes three older partial fixes; that cross-PR coordination is a maintainer call.

[robobun]

Consolidation note. I pushed bb390cb to this branch while sorting out the open PRs that overlap on this path (#33356, #34193, #37981, #38116, #32814).

It carries the one piece of #37981 that was missing here: the exit-13 stamp in spin() now also checks has_requested_terminate(), like the enclosing 'beforeExit' condition. process.on("beforeExit", () => process.exit(0)) with a pending top-level await exited 13; Node exits 0.

It also folds in the tests from the superseded PRs that exercise paths this PR fixes but did not test:

• event loop: report promise rejections left by the turn that let the loop go idle #37981: repl -e last-timer rejection, two main-thread 'beforeExit' orderings in process.test.js, three top-level-await rows in the worker table, and "reported before tasks the same turn queued".
• worker_threads: exit code 1 when a Worker dies from an unhandled rejection #34193: worker-error-exit-code.test.ts unchanged (message-listener and timer sites, the worker's own 'exit' argument, listener suppression).
• Drain the microtask checkpoint after unhandledRejection handlers run #33356: a main-thread listener that recovers from a 'beforeExit' rejection after a microtask hop.

All of them fail on 1.4.3 and pass on this branch (Linux x64 debug+ASAN; worker_threads.test.ts 160/160, repl.test.ts 128/128, the process.onBeforeExit block 16/16). #37981 and #34193 are closed in favor of this PR, #33356 in favor of #42031 plus this PR.

[claude]

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

Still open from earlier reviews (1):

• Unresolved: 1 minor or pre-existing.

[claude]

I re-reviewed the six new commits and found no bugs; since this reworks exit-code and shutdown ordering across the main thread, workers and the REPL, a human look is still worthwhile before merging.

What was reviewed:

• fail_exit_code now queries the VM's own global (self.global()), the REPL's interactive flag is set on the loop branch that piped and TTY sessions share, and the worker error path's request_termination() after worker.exit() stops the 'exit' listeners left after one throws — each of the earlier inline points is addressed in the code, with a test per case.
• Traced the process.exitCode = 4 / listener-sets-98 + throwing 'exit' listener cases on the main thread: on_before_exit arms the hard-exit arm when an error was counted, so process_exit(code) runs before print_unhandled_version_note can overwrite the code.
• Checked dispatch_on_before_exit's new drain + handle_rejected_promises and the two auto_tick_active tails against a stop requested mid-drain: drain_microtasks returns Stopped on a termination and the rejection pass is skipped; the on_before_exit loop already re-checks script_allowed() between ticks.

Extended reasoning...

The diff touches VirtualMachine.rs (new fail_exit_code helper replacing three exit_code = 1 sites, a microtask/rejection checkpoint after 'beforeExit'), jsc_hooks.rs (auto_tick_active now runs handleRejectedPromises on both return paths), web_worker.rs (worker 'exit' listeners run before the VM is marked shutting down; error path ends via WebWorker::exit plus request_termination), two small C++ probes reading Process flags, a one-line REPL flag, and about 380 lines of subprocess tests. It touches no auth, crypto, or input-parsing surface. The hunt ran dry with no findings, the prior inline points from earlier runs are addressed in the new commits, and every behavioral change has a spawned-subprocess test, but the change alters shutdown semantics shared by the main thread, workers and the REPL, which is why a human look is recommended rather than an approval.

Still open from earlier reviews (3):

• Unresolved: 3 minor or pre-existing.

[robobun]

#42031, the base of this PR, is closed in favor of #45597. Two more open PRs cover part of this one, so I converted it to a draft.

I merged #45597, #45582 and #45575 into main at 91e7e3b and ran the 41 test cases of this PR on that build. 27 pass and 14 fail. Node 26.3.0 gives the expected result for each of the 14.

Covered:

• Report unhandled rejections made in the event loop's last turn #45582 makes the same two source changes: the rejection pass at the end of auto_tick_active and after the 'beforeExit' listeners. All last-turn worker cases and all 'beforeExit' cases pass.
• process: 'exit' listeners see exit code 1 after an unhandled rejection #45575 covers the exit code that a worker's 'exit' listeners and its parent see after a rejection. It stores the code in Run::start and in the worker's error handler, not in the shared rejection path. So bun repl needs no flag for a rejection.

Not covered (the 14 cases):

• Main thread, 7 cases: an 'exit' listener that throws replaces the exit code in effect with 1. With process.exitCode = 4, Node exits 4 and bun exits 1. The same applies to process.exit(7), process.exit(0) and a code that the listener sets.
• Main thread, 1 case: process.exit() with no argument after a reported rejection exits 0.
• Worker, 4 cases: a throw from an 'exit' listener is not reported to the parent, the listeners after it still run, and under process.exit(4) the code becomes 1.
• Worker, 1 case: process.exit(0) from 'beforeExit' while a top-level await is pending exits 13.
• REPL, 1 case: a throw from a timer during a session makes bun repl exit 1.

When #45582 and #45575 merge, I will rebase this PR onto main and cut it down to these cases.