Exit unsettled top-level await instead of hanging / busy-looping

[robobun]

Fixes #29546
Fixes #14951

Reproduction

async function run(signal: AbortSignal): Promise<string> {
  return new Promise((resolve) => {
    signal.addEventListener('abort', () => resolve('run aborted'));
  });
}

const r = await run(AbortSignal.timeout(2000));
console.log(r);

Before: Windows hangs forever, POSIX spins one core at 100% for the full 2s before the timer fires.
After: exits cleanly with no output (matches Node.js).

Root cause

AbortSignal.timeout(N) inserts a timer into Bun's own heap but deliberately does not bump active_timer_count — it's unref'd by design. When the only thing holding up a top-level await is that unref'd timer, autoTick()'s two platform paths both misbehave:

• POSIX: loop.isActive() is false, so we take the tickWithoutIdle() branch (zero-timeout poll) and then drainTimers(). That drains the unref'd timer eventually — but only after the waitForPromise loop spins until the deadline, burning one full core.

• Windows: tickWithoutIdle → us_loop_pump → uv_run(UV_RUN_NOWAIT). uv_run early-returns when uv__loop_alive() is false (vendor/libuv/src/win/core.c:719) — and with no ref'd handles it is. So the uv timer that would normally drain Bun's heap via onUVTimer never fires. Hang forever.

Fix

Add two helpers on EventLoop:

• hasAnyHandleWork() — returns true if anything could still wake the loop (active uv/uws handles, queued tasks, concurrent refs, immediates). Intentionally NOT VirtualMachine.isEventLoopAlive(), which short-circuits on unhandled_error_counter != 0 — a side-path unhandled rejection during a TLA wait must NOT abandon an in-flight fetch that will resolve the TLA.
• waitForPromiseOrLoopExit() — identical to waitForPromise except it breaks when hasAnyHandleWork() returns false.

Route loadEntryPoint (both the watcher and non-watcher branches) through it. This is the "run the main script" entry point — bun run foo.ts, bun foo.ts, bun -e '…'.

waitForPromise itself is unchanged, and loadEntryPointForTestRunner / loadPreloads / waitForPromiseWithTermination (workers) also keep the old waitForPromise contract. Several callers rely on "returns with the promise resolved" — most visibly Expect.getValueAsToThrow (src/bun.js/test/expect.zig:589), which asserts .pending => unreachable after the wait. Breaking that contract is what caused the test-runner regressions in the earlier attempt at this fix (#27215). A test-file's top-level-await-only-held-by-an-unref'd-timer can still hang bun test today; that's a narrower, separate bug and out of scope here.

The new behavior matches Node.js: an unsettled top-level await in the main script exits cleanly (with a warning, on Node ≥ 20) rather than waiting on unref'd handles.

Verification

$ bun bd test test/regression/issue/29546.test.ts
✓ AbortSignal.timeout awaited at top-level does not hang or spin
✓ AbortSignal.timeout fires when something else keeps the loop alive
✓ top-level await on a never-resolving promise exits cleanly
✓ unhandled rejection mid-TLA does not abandon an in-flight wait

Checked out origin/main on src/bun.js/event_loop.zig + src/bun.js/VirtualMachine.zig, rebuilt, and ran the tests → 2 fail on the 5s test timeout (hang confirmed), 2 pass (the "keeps the loop alive" regression guard + the "unhandled rejection" guard). Restored the fix, rebuilt → all 4 pass in <1s each.

The "fires when something else keeps the loop alive" test is the regression guard for the original bug — with a ref'd setTimeout holding the loop open, the unref'd AbortSignal.timeout still fires on schedule and the listener still runs.

The "unhandled rejection mid-TLA" test pins the hasAnyHandleWork() vs isEventLoopAlive() distinction: a side-path unhandled rejection must NOT cause the TLA wait to bail while real work (here, a setTimeout) is still pending. If the liveness check ever gets simplified to isEventLoopAlive(), this test will catch it.

Also re-ran test/js/node/timers/*, test/regression/issue/28756.test.ts (AbortSignal memory-leak), and the TLA regressions (#20100 / #21257 / #24007 / #28914) — all pass.

[robobun]

^{Updated 4:06 PM PT - May 5th, 2026}

❌ @robobun, your commit ab4b3b4 has 1 failures in Build #51815 (All Failures):

• test/js/bun/test/parallel/test-http-should-emit-close-when-connection-is-aborted.ts - timeout on 🪟 2019 x64
• test/js/bun/test/parallel/test-http-should-emit-close-when-connection-is-aborted.ts - timeout on 🪟 2019 x64-baseline
• test/js/bun/test/parallel/test-http-should-emit-close-when-connection-is-aborted.ts - timeout on 🪟 11 aarch64

---

🧪   To try this PR locally:

bunx bun-pr 29549

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

bun-29549 --bun

[github-actions]

Found 2 issues this PR may fix:

1. awaiting top level no-op promise that never resolves is missing an error/warn, causing 100% cpu usage #14951 - Exact match: await new Promise(r => {}) at top level causes 100% CPU usage, which is precisely the unsettled TLA busy-loop that waitForPromiseOrLoopExit now breaks out of cleanly.
2. Bun process does not exit after Tinypool destroy() completes (worker threads remain alive) #29173 - After Tinypool.destroy() completes, worker threads are terminated but the process hangs on the top-level await because no ref'd handles remain; the new loop-exit check would cause the process to exit cleanly instead of hanging.

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

Fixes #14951
Fixes #29173

🤖 Generated with Claude Code

[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

Adds event-loop liveness checks and a new wait variant so awaiting a promise can exit early when the loop has no remaining handle work; integrates this into VirtualMachine.loadEntryPoint. Adds regression tests validating top-level await behavior with timeouts, never-resolving promises, and unhandled rejections.

Changes

Cohort / File(s)	Summary
Virtual Machine changes src/bun.js/VirtualMachine.zig	loadEntryPoint wait logic adjusted: watcher path breaks pending-promise loop if promise still .pending but eventLoop().hasAnyHandleWork() is false; non-watcher path now uses eventLoop().waitForPromiseOrLoopExit(...) instead of waitForPromise(...), allowing earlier exit when the loop has no handle work.
Event loop helpers src/bun.js/event_loop.zig	Added pub fn hasAnyHandleWork(this: *EventLoop) bool and pub fn waitForPromiseOrLoopExit(this: *EventLoop, promise: jsc.AnyPromise) void. hasAnyHandleWork aggregates liveness signals (loop handles, task counters, ref state, immediate queues); waitForPromiseOrLoopExit mirrors the tick/microtask loop but can terminate if no handle work remains.
Regression tests test/regression/issue/29546.test.ts	Adds five Bun regression tests that spawn separate Bun processes to exercise top-level await with AbortSignal.timeout(...), unref'd timers, never-resolving promises, and unhandled rejections; each asserts timing, stdout, and exit codes to ensure processes exit correctly (no hang or busy-spin).

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately captures the main change: fixing top-level await hanging/busy-looping when only held by unref'd timers.
Description check	✅ Passed	The description comprehensively covers root cause, fix details, verification, and regression testing, but lacks explicit 'How did you verify your code works?' section as required by template.
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.

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

[github-actions]

This PR may be a duplicate of:

1. fix: detect unsettled top-level await and exit instead of busy-waiting #27215 - Also fixes unsettled top-level await causing busy-looping/hanging by detecting when the event loop has no active handles while a TLA promise is still pending

🤖 Generated with Claude Code

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/bun.js/VirtualMachine.zig (1)

2145-2167: ⚠️ Potential issue | 🟠 Major

Don't treat a still-pending preload as success.

waitForPromiseOrLoopExit() can now return with promise.status() == .pending, but loadPreloads() still only returns the promise on .rejected. In that case the preload silently falls through and the main entry point starts loading even though the preload never finished.

Suggested fix

-        if (promise.status() == .rejected)
-            return promise;
+        switch (promise.status()) {
+            .fulfilled => {},
+            else => return promise,
+        }

Also applies to: 2169-2170

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/bun.js/VirtualMachine.zig` around lines 2145 - 2167, The code assumes
waitForPromiseOrLoopExit(.{ .internal = promise }) always yields
resolved/rejected, but it can return while promise.status() == .pending causing
loadPreloads()/pending_internal_promise to silently fall through; update the
non-watcher branch to check this pending_internal_promise?.status() after
eventLoop.waitForPromiseOrLoopExit and treat .pending like an error or continue
waiting (e.g., loop until status != .pending or explicitly convert pending to
.rejected), and mirror the same guard/handling in loadPreloads() (and the
referenced lines ~2169-2170) so the main entry point never proceeds when a
preload remains pending; reference functions/fields:
eventLoop.waitForPromiseOrLoopExit, pending_internal_promise, loadPreloads,
isWatcherEnabled, eventLoop.performGC.

🤖 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/29546.test.ts`:
- Around line 24-29: Remove the brittle assertions that require an empty stderr
in the subprocess regression tests: delete any
expect(stripAsanWarning(stderr)).toBe("") (or expect(stderr).toBe("")) checks in
the tests that spawn bunExe() with bunEnv and instead rely on stdout and
exitCode as the regression signal; search for uses of stripAsanWarning and
remove the empty-stderr expectations (including the other occurrences in this
test file).

---

Outside diff comments:
In `@src/bun.js/VirtualMachine.zig`:
- Around line 2145-2167: The code assumes waitForPromiseOrLoopExit(.{ .internal
= promise }) always yields resolved/rejected, but it can return while
promise.status() == .pending causing loadPreloads()/pending_internal_promise to
silently fall through; update the non-watcher branch to check this
pending_internal_promise?.status() after eventLoop.waitForPromiseOrLoopExit and
treat .pending like an error or continue waiting (e.g., loop until status !=
.pending or explicitly convert pending to .rejected), and mirror the same
guard/handling in loadPreloads() (and the referenced lines ~2169-2170) so the
main entry point never proceeds when a preload remains pending; reference
functions/fields: eventLoop.waitForPromiseOrLoopExit, pending_internal_promise,
loadPreloads, isWatcherEnabled, eventLoop.performGC.

🪄 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: 808f2194-8307-4e09-ba3f-9936db83c37b

📥 Commits

Reviewing files that changed from the base of the PR and between 7c73f05 and c6fe5d9.

📒 Files selected for processing (3)

• src/bun.js/VirtualMachine.zig
• src/bun.js/event_loop.zig
• test/regression/issue/29546.test.ts

[coderabbitai]

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/29546.test.ts`:
- Around line 4-25: Remove the long file-level bug-history block at the top of
test/regression/issue/29546.test.ts and replace it with only the issue URL and a
one-line summary; keep the per-test rationale comments that explain why the
timings/fixtures detect the regression. Concretely, trim out the multi-paragraph
explanation referencing loadEntryPoint, EventLoop.waitForPromiseOrLoopExit,
waitForPromise and Expect.toThrow so the header contains just the issue link and
a concise summary, while leaving any inline test comments that describe test
design and timing choices intact.

🪄 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: 25b27b14-7959-457b-b514-43cc96534d8e

📥 Commits

Reviewing files that changed from the base of the PR and between 2858b4c and 6a6c742.

📒 Files selected for processing (1)

• test/regression/issue/29546.test.ts

[coderabbitai]

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/event_loop.zig`:
- Around line 591-600: The hasAnyHandleWork function is checking
vm.event_loop_handle.?.isActive() which on Windows references the libuv loop
instead of the uSockets loop; update that check to use
this.usocketsLoop().isActive() (preserving the optional/null-safety semantics
used elsewhere) so the early-exit condition used by waitForPromiseOrLoopExit
correctly observes uws I/O activity; locate hasAnyHandleWork and replace the
vm.event_loop_handle.?.isActive() term with an equivalent
this.usocketsLoop().isActive() call consistent with
autoTick()/tickPossiblyForever()/autoTickActive().

🪄 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: 8b9bb2d9-017c-4b39-ba48-99d5c77dd809

📥 Commits

Reviewing files that changed from the base of the PR and between 6a6c742 and 1b814e9.

📒 Files selected for processing (1)

• src/bun.js/event_loop.zig

[coderabbitai]

♻️ Duplicate comments (1)

src/bun.js/event_loop.zig (1)

591-600: ⚠️ Potential issue | 🟠 Major

Use this.usocketsLoop().isActive() instead of vm.event_loop_handle.?.isActive() on Windows.

On Windows, vm.event_loop_handle is the libuv loop while usocketsLoop() returns this.uws_loop (uSockets). Other functions in this file (autoTick(), tickPossiblyForever(), autoTickActive()) use usocketsLoop() for cross-platform consistency.

Checking the wrong loop could cause the early-exit condition in waitForPromiseOrLoopExit() to trigger incorrectly on Windows when there's still pending work in the uws I/O loop.

🔧 Suggested fix

 pub fn hasAnyHandleWork(this: *EventLoop) bool {
     const vm = this.virtual_machine;
-    return vm.event_loop_handle.?.isActive() or
+    return this.usocketsLoop().isActive() or
         vm.active_tasks > 0 or
         this.tasks.count > 0 or
         this.hasPendingRefs() or

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/bun.js/event_loop.zig` around lines 591 - 600, Replace the libuv loop
check with the uSockets loop check in hasAnyHandleWork: currently it calls
vm.event_loop_handle.?.isActive(), which on Windows inspects the wrong loop;
change it to use this.usocketsLoop().isActive() so the function
(hasAnyHandleWork) correctly reflects uSockets activity (matching other
functions like autoTick, tickPossiblyForever, autoTickActive) and avoids
premature exit in waitForPromiseOrLoopExit().

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@src/bun.js/event_loop.zig`:
- Around line 591-600: Replace the libuv loop check with the uSockets loop check
in hasAnyHandleWork: currently it calls vm.event_loop_handle.?.isActive(), which
on Windows inspects the wrong loop; change it to use
this.usocketsLoop().isActive() so the function (hasAnyHandleWork) correctly
reflects uSockets activity (matching other functions like autoTick,
tickPossiblyForever, autoTickActive) and avoids premature exit in
waitForPromiseOrLoopExit().

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: e8fba4f3-bb15-4626-9123-135496f56c50

📥 Commits

Reviewing files that changed from the base of the PR and between 1b814e9 and 71dfe8b.

📒 Files selected for processing (2)

• src/bun.js/event_loop.zig
• test/regression/issue/29546.test.ts

[claude]

The fix logic is sound and all previously raised concerns have been addressed, but the event-loop liveness semantics (especially on Windows where is libuv while is uSockets) are subtle enough that a human familiar with Bun's Windows port should give this a final pass before merge.

Extended reasoning...

Overview

PR adds and to , then routes (both watcher and non-watcher branches) through the new function. Also adds between and the liveness check in the watcher branch to prevent silent microtask loss. A regression test file with 5 targeted scenarios is included.

Security Risks

None — this is pure event-loop scheduling logic with no auth, crypto, or I/O boundary changes.

Level of Scrutiny

High. This touches the event loop tick loop, which is among the most critical code paths in the runtime. Correctness failures here manifest as silent data loss (TLA continuations dropped, module init skipped) rather than hard crashes, making them difficult to detect in CI.

Other Factors

All inline concerns raised in previous review passes are marked resolved: the / bug was fixed via the new , the worker TLA change was correctly reverted, is checked, the microtask drain is present, and assertion ordering in tests was fixed. The one remaining open question — whether (libuv on Windows) is the right liveness proxy vs (uSockets) — was raised by CodeRabbit and marked resolved without a visible code change. That distinction is harmless on POSIX (same object) but could produce an incorrect early-exit on Windows if a uSockets handle is active while libuv is not. The scope decision to leave and on the old path is explicitly documented and reasonable.

[claude]

All previously identified issues have been addressed, but this PR introduces novel event loop control flow in critical infrastructure — a human should verify the final state.

Extended reasoning...

Overview

This PR adds two new event loop helpers ( and ) to fix POSIX busy-looping at 100% CPU and Windows infinite hangs when top-level await is held only by an unref'd timer. The changes touch and , with a regression test file added.

Security risks

None. This is event loop scheduling logic with no auth, crypto, or permission implications.

Level of scrutiny

High. The event loop is among the most critical code paths in Bun. The fix introduces a new liveness predicate () and a new wait variant (), both with subtle correctness requirements: they must be conservative (never exit while real work is pending) while also being aggressive enough to exit when only unref'd work remains. Multiple real bugs were found and addressed during this review cycle, indicating the code needed careful iteration.

Other factors

All of my previous inline bug reports (7 in total) were addressed in commit 36da1f7 — fixing the short-circuit issue, adding to the liveness check, adding microtask drains in both the non-watcher and watcher branches, and reverting the unneeded worker change. The test suite is comprehensive with 5 tests covering the regression, the keep-alive guard, never-resolving TLA, unhandled-rejection-during-wait, and the subtle unhandledRejection-handler-resolves-TLA case. No new bugs were surfaced by the bug hunting system. The PR is well-reasoned and in good shape; a human reviewer should verify the final implementation before merge.

[claude]

All earlier review feedback has been addressed and I didn't find anything new this round, but this changes the core TLA wait/exit semantics in the event loop (and the prior attempt #27215 regressed), so it's worth a human pass before merge.

Extended reasoning...

Overview

This PR adds EventLoop.hasAnyHandleWork() and EventLoop.waitForPromiseOrLoopExit() in src/bun.js/event_loop.zig, and routes loadEntryPoint (both watcher and non-watcher branches) in src/bun.js/VirtualMachine.zig through the new wait variant. The net effect is that an unsettled top-level await with no ref'd handles now exits cleanly instead of busy-looping (POSIX) or hanging (Windows). A new regression test file with five subprocess tests pins the behavior.

Over six prior review rounds I flagged: (1) the original isEventLoopAlive() predicate short-circuiting on unhandled_error_counter, (2) an unintended change to waitForPromiseWithTermination, (3) missing concurrent_tasks in the liveness check, (4) a missing microtask drain between autoTick() and the liveness break, and (5) the same drain missing from the watcher branch. All of these have been addressed in the current diff, and the bug-hunting pass on the latest revision found nothing new.

Security risks

None. This is purely event-loop scheduling/exit logic; no auth, crypto, parsing, or untrusted-input surfaces are touched.

Level of scrutiny

High. event_loop.zig and VirtualMachine.loadEntryPoint are on the hot path for every bun run / bun foo.ts invocation, and this PR changes when the process exits — a user-visible semantic. The previous attempt at this fix (#27215) caused test-runner regressions, and this PR went through several correctness iterations before stabilizing. The liveness predicate aggregates seven signals across two platforms; subtle mis-ordering or a missed signal can silently drop work. That warrants a maintainer's eyes, not an auto-approve.

Other factors

• waitForPromise itself is deliberately unchanged, and loadEntryPointForTestRunner / loadPreloads keep the old contract (the PR description scopes the test-runner case as a separate bug). That scoping decision is reasonable but worth a maintainer ack.
• CodeRabbit raised usocketsLoop() vs event_loop_handle on Windows; the thread is marked resolved but the code still uses event_loop_handle (matching isEventLoopAliveExcludingImmediates). Likely correct, but a Windows-familiar reviewer should confirm.
• CI shows two failures (in-process-cron, bun-install) that the latest commit message attributes to pre-existing flakes; they don't appear related to this change.
• The microtask drain is now gated behind \!hasAnyHandleWork() (only runs on the about-to-break iteration), which keeps the steady-state loop identical to waitForPromise — a nice property for perf, but also means the drain only covers the one known edge case rather than every iteration.

[claude]

No issues found in this revision, but this reworks core event-loop liveness + TLA exit semantics and the --hot reload state machine (with Windows-specific direct reads of libuv internals), so it needs a human sign-off — also worth confirming the Windows test-http-should-emit-close-when-connection-is-aborted.ts timeouts in Build #51503 are pre-existing flakes and not related to the loop changes here.

Extended reasoning...

Overview

Touches three files: src/jsc/event_loop.zig (adds hasAnyHandleWork, hasAnyHandleWorkIgnoringForeverTimer, waitForPromiseOrLoopExit), src/jsc/VirtualMachine.zig (routes loadEntryPoint's TLA wait through the new helper, reworks reload() and reportExceptionInHotReloadedModuleIfNeeded for the abandoned-TLA case under --hot, adds a post-reloadEntryPoint microtask drain), and a new 256-line regression test. The change alters when a Bun process decides to exit vs. keep waiting on a top-level await — core process-lifecycle semantics.

Security risks

None identified. No auth/crypto/permissions surface; the change is internal event-loop scheduling. The behavioral change (exit instead of wait on unref'd handles) matches Node.js semantics and is not a security boundary.

Level of scrutiny

High. This is production-critical runtime code: the event loop's liveness predicate and the entry-point promise-wait loop affect every bun run / bun -e invocation. The Windows branch of hasAnyHandleWorkIgnoringForeverTimer reads libuv internal struct fields (active_handles, active_reqs.count, pending_reqs_tail, endgame_handles) directly and applies a heuristic subtraction for forever_timer. The --hot reload changes alter when the module registry is torn down vs. deferred. A prior attempt at this same fix (#27215) caused test-runner regressions, and this PR went through ~15 rounds of automated review correcting subtle issues (the unhandled_error_counter short-circuit, worker-TLA revert, Windows forever_timer masking, zombie-continuation ordering, stranded hot_reload_deferred, out-of-tick() microtask drain). All of those are now resolved, but the iteration count itself signals the subtlety.

Other factors

• All prior inline review comments are marked resolved and the latest commit (e86f538) addresses the last one.
• Build #51503 (one commit back, 5215594) shows test-http-should-emit-close-when-connection-is-aborted.ts timing out on three Windows lanes plus a Windows build-agent infra failure. loadEntryPointForTestRunner was deliberately left unchanged so this is plausibly a pre-existing flake, but given the PR does change Windows event-loop liveness it's worth a human confirming before merge.
• Good test coverage for the specific scenarios fixed (six regression tests including a --hot round-trip test), and the PR description documents re-running the related TLA/timer regression suites.

This is not a candidate for auto-approval — it's a substantive runtime behavior change that warrants maintainer review.

[claude]

No bugs found in the current revision, but this reworks core event-loop liveness + the --hot reload deferral path (including Windows-specific reads of libuv loop internals) across enough subtle iterations that a human pass on the final shape is warranted.

Extended reasoning...

Overview

This PR changes how Bun handles unsettled top-level await in the main entry point, plus a substantial rework of the --hot reload deferral path that fell out of it. Touched surfaces:

• src/jsc/event_loop.zig: new hasAnyHandleWork(), hasAnyHandleWorkIgnoringForeverTimer() (Windows branch reads uv_loop_t internal fields directly: active_handles, active_reqs.count, pending_reqs_tail, endgame_handles), and waitForPromiseOrLoopExit().
• src/jsc/VirtualMachine.zig: loadEntryPoint watcher-loop break, reload() .pending arm restructured (drain → re-switch → liveness gate), a new .pending consumer in reportExceptionInHotReloadedModuleIfNeeded, and a post-reloadEntryPoint microtask drain.
• New regression test with 6 cases including a --hot round-trip test.

Security risks

None identified — this is scheduling/liveness logic with no auth, parsing, or external-input surface.

Level of scrutiny

High. This is the core event-loop tick path and the --hot reload state machine — code that runs on every bun run and every file save under --hot. The PR went through ~14 commits responding to a long chain of subtle ordering/race findings (unhandled-error-counter short-circuit, concurrent_tasks race, Windows forever_timer keeping uv_loop_alive true, microtask-drain placement relative to liveness checks, stranded hot_reload_deferred under coalesced watcher events). Each individual fix looks correct in isolation, but the cumulative interaction between reload(), reportExceptionInHotReloadedModuleIfNeeded(), loadEntryPoint's watcher loop, and tickPossiblyForever() is now intricate enough that a maintainer should sign off on the final shape — particularly the Windows branch that subtracts forever_timer from raw uv_loop_t.active_handles and the decision to drain microtasks at the tail of reload() for all call sites.

Other factors

• All prior inline findings are addressed and resolved; no open bugs in the current revision.
• Good regression coverage (6 tests pinning the TLA exit, the unhandled-rejection edge, and the --hot reload-after-abandoned-TLA path), though the most contorted edge cases (coalesced watcher events, ref'd→abandoned transition) are not directly tested.
• A prior attempt at this same fix (#27215) was reverted for test-runner regressions, which is why this version deliberately leaves waitForPromise / loadEntryPointForTestRunner / loadPreloads untouched — that scoping decision itself is worth a human nod.

[claude]

No new issues from the bug hunter on this revision — but this rewires core event-loop liveness (TLA exit semantics, reload() deferral, platform-specific libuv internals on Windows), so it warrants a human pass before merge.

Extended reasoning...

Overview

This PR changes how Bun handles unsettled top-level await in the main entry point. It touches three areas:

• src/jsc/event_loop.zig: adds hasAnyHandleWork(), hasAnyHandleWorkIgnoringForeverTimer() (which on Windows reads raw libuv loop fields — active_handles, active_reqs.count, pending_reqs_tail, endgame_handles — and subtracts the forever_timer contribution), and waitForPromiseOrLoopExit().
• src/jsc/VirtualMachine.zig: routes loadEntryPoint's TLA wait through the new helper (both watcher and non-watcher branches), rewrites reload()'s .pending deferral to distinguish abandoned TLAs from ref'd-I/O TLAs, adds a stranded-flag consumer in reportExceptionInHotReloadedModuleIfNeeded, and adds a post-reloadEntryPoint microtask drain.
• test/regression/issue/29546.test.ts: six regression tests covering the exit, the keep-alive guard, the isEventLoopAlive vs hasAnyHandleWork distinction, the unhandledRejection-handler microtask race, and --hot reload after an abandoned TLA.

Security risks

None identified. This is process-lifetime / event-loop scheduling logic; no auth, crypto, parsing of untrusted input, or permissions surface is touched.

Level of scrutiny

High. This is production-critical runtime code that determines when bun run exits and how --hot decides to reload. The change history on this PR (15+ iterations, each fixing a subtle race or platform divergence found in the previous one) demonstrates exactly how delicate the liveness predicate is. The Windows branch of hasAnyHandleWorkIgnoringForeverTimer reaches directly into libuv's uv_loop_t struct layout and applies a heuristic subtraction — that alone deserves a maintainer's eyes. The reload() rewrite changes when the module registry is torn down relative to in-flight TLA continuations, which is a meaningful semantic shift for --hot.

Other factors

• All prior inline review comments (mine, CodeRabbit's) are now resolved; the accidental-revert commit (630731d) flagged in my last review has been removed from history and the source changes are restored.
• The bug-hunting system found no new issues on this revision.
• CI on the latest commit shows only infrastructure failures (BuildKite agent creation / fleet issues), not test failures — but that also means the latest revision hasn't yet had a clean full-matrix run, including the Windows lanes that exercise the libuv-specific path.
• A prior attempt at this fix (#27215) caused test-runner regressions; this PR carefully scopes the new behavior to loadEntryPoint only, but the interaction surface (hot-reload deferral, forever_timer, microtask draining order) is broad enough that a human should sign off on the design.

This is well outside the "simple, mechanical, obvious" bar for auto-approval.

[claude]

No remaining issues from my side — every prior comment has been addressed and the latest commit picks up the tail-recurse fix. I'm not auto-approving only because this touches the core event-loop liveness predicate, loadEntryPoint, and the --hot reload state machine (with Windows-specific raw uv-loop field reads), which feels like it warrants a human sign-off.

Extended reasoning...

Overview

This PR changes how Bun handles an unsettled top-level await in the main entry point so the process exits cleanly (matching Node.js) instead of busy-spinning on POSIX or hanging forever on Windows. It touches three files:

• src/jsc/event_loop.zig: adds hasAnyHandleWork(), hasAnyHandleWorkIgnoringForeverTimer() (Windows reads raw uv_loop_t fields: active_handles, active_reqs.count, pending_reqs_tail, endgame_handles), and waitForPromiseOrLoopExit().
• src/jsc/VirtualMachine.zig: routes loadEntryPoint's TLA wait through the new variant; reworks reload()'s .pending arm to distinguish abandoned TLAs from in-flight ref'd I/O; adds a stranded-hot_reload_deferred consumer in reportExceptionInHotReloadedModuleIfNeeded with a tail-recurse to re-read the fresh promise; adds a post-reloadEntryPoint microtask drain.
• test/regression/issue/29546.test.ts: six regression tests including a --hot watcher round-trip test.

Security risks

None identified. No auth, crypto, permissions, or untrusted-input parsing is involved; the change is purely event-loop scheduling/liveness logic.

Level of scrutiny

High. loadEntryPoint and EventLoop.autoTick/waitForPromise are on the hot path of every bun run / bun -e invocation, and the --hot reload state machine has subtle ordering invariants (defer vs. proceed, microtask drain timing, Windows forever_timer ref accounting). The PR went through ~15 iterative review rounds where real correctness issues were found and fixed at each step (unhandled-error-counter short-circuit, concurrent_tasks race, microtask-drain-before-liveness ordering, Windows forever_timer keeping uv_loop_alive permanently true, zombie-continuation regression in reload(), stranded-defer triggers, accidental source revert in a "ci: retrigger" commit). All of those are now resolved and pinned by tests, but the density of subtle interactions argues for a maintainer's eyes on the final shape rather than bot-only approval.

Other factors

• All 15+ prior inline comments (mine and CodeRabbit's) are marked resolved; the most recent commit (360dfa4) directly implements my last suggestion (tail-recurse after reload()).
• The bug-hunting system found no issues on this revision.
• Test coverage is good: the six new tests pin the primary fix, the regression guard, the isEventLoopAlive vs hasAnyHandleWork distinction, the microtask-drain-before-break, and the --hot reload-after-abandoned-TLA path.
• This is not a mechanical/config change — it's a semantic change to runtime exit behavior and the hot-reload defer/proceed decision, which is exactly the kind of design surface a human should ratify.

[claude]

No new issues found on this pass, but this rewires core event-loop liveness (TLA exit semantics, --hot reload's .pending deferral, Windows-specific uv handle accounting) — worth a human sign-off given the blast radius and the number of iterations it took to converge.

Extended reasoning...

Overview

This PR changes how Bun handles unsettled top-level await in the main entry point. It adds three new EventLoop helpers (hasAnyHandleWork, hasAnyHandleWorkIgnoringForeverTimer, waitForPromiseOrLoopExit) in src/jsc/event_loop.zig, and routes loadEntryPoint through them instead of the blocking waitForPromise. It also substantially reworks the --hot reload path in src/jsc/VirtualMachine.zig: reload()'s .pending arm now drains microtasks and consults a forever-timer-aware liveness check before deferring, reportExceptionInHotReloadedModuleIfNeeded gains a stranded-flag consumer with tail-recursion, and reload() drains microtasks after reloadEntryPoint for out-of-tick() callers. A 256-line regression test file covers six scenarios including a --hot round-trip test.

Security risks

None identified. No auth, crypto, permissions, or untrusted-input parsing is touched. The change is purely about event-loop scheduling and process-exit timing.

Level of scrutiny

High. This is the core runtime event loop — the code that decides whether a Bun process keeps running or exits. The change has platform-divergent behavior (POSIX uws active counter vs. Windows uv_loop_alive / active_handles / active_reqs), interacts with hot-reload state machines, and introduces a new exit state (loadEntryPoint returning with a still-.pending promise) that downstream code was not originally designed for. The Windows hasAnyHandleWorkIgnoringForeverTimer heuristic directly reads libuv internals (active_handles, active_reqs.count, pending_reqs_tail, endgame_handles) and subtracts an assumed contribution — the in-code comment explicitly calls it a heuristic.

Other factors

The PR went through roughly twenty review iterations over two weeks, with multiple substantive bugs found and fixed along the way (using isEventLoopAlive instead of raw handle liveness, missing concurrent_tasks check, missing microtask drain before the liveness break, the forever_timer Windows issue, the ref'd-vs-abandoned TLA distinction in reload(), an accidental full revert in a "ci: retrigger" commit, etc.). All inline comments are resolved except one trivial comment-wording nit about a hardcoded line number. An earlier attempt at this same fix (#27215) caused test-runner regressions, which is why the scope was carefully narrowed to loadEntryPoint only. Given the subtlety, the platform-specific reasoning, and the history, this should get human eyes before merge.

[claude]

I didn't find any new issues, but this changes core event-loop liveness semantics (waitForPromiseOrLoopExit, hasAnyHandleWork*) plus the --hot reload state machine, with platform-specific libuv internals on Windows — worth a human sign-off given how many subtle interactions surfaced during iteration.

Extended reasoning...

Overview

This PR changes how Bun's main entry point waits on a top-level await: instead of spinning/hanging when only unref'd work is pending, loadEntryPoint now routes through a new EventLoop.waitForPromiseOrLoopExit that breaks once hasAnyHandleWork() reports nothing left to make progress. It also adds hasAnyHandleWorkIgnoringForeverTimer() (Windows-specific carve-out reading raw uv_loop.active_handles / active_reqs.count / pending_reqs_tail / endgame_handles), reworks reload()'s .pending deferral and reportExceptionInHotReloadedModuleIfNeeded() so --hot recovers after an abandoned TLA, and adds a post-reloadEntryPoint microtask drain. Six regression tests cover the main fix plus the unhandledRejection/--hot edge cases.

Security risks

None identified. This is event-loop control-flow / process-liveness logic; no auth, crypto, parsing of untrusted input, or permission surfaces are touched.

Level of scrutiny

High. src/jsc/event_loop.zig and src/jsc/VirtualMachine.zig are core runtime — the predicate that decides whether the process exits, and the --hot reload state machine. The Windows branch of hasAnyHandleWorkIgnoringForeverTimer reads libuv internals directly and subtracts a heuristic forever_timer contribution. The PR went through ~20 review iterations in which the bug-hunting system found several real issues (the isEventLoopAlive short-circuit on unhandled_error_counter, missing concurrent_tasks check, missing microtask drain before the liveness break, the Windows forever_timer ref'd-handle problem, the zombie-continuation regression in reload()'s .pending fall-through) — all addressed, but the density of subtle interactions argues for a maintainer who knows the event-loop invariants to sign off.

Other factors

• An earlier attempt at this fix (#27215) caused test-runner regressions; this PR explicitly scopes the new behavior to loadEntryPoint only and leaves waitForPromise / loadEntryPointForTestRunner / waitForPromiseWithTermination unchanged, which is the right call but means a maintainer should confirm the scoping.
• One open inline nit remains (the beforeExit follow-up at event_loop.zig:700) — explicitly labeled non-blocking / out-of-scope.
• CI build #51693 has test-http-should-emit-close-when-connection-is-aborted.ts timing out on three Windows lanes; commit messages reference this as a known cross-PR flake (#30217), but a human should confirm it's unrelated before merge.
• This is a user-visible behavior change (unsettled TLA now exits instead of waiting), aligning with Node.js but still a semantic shift.

[claude]

🟡 nit: the doc-comment on hasAnyHandleWork() references "the hot-reloader watcher at hot_reloader.zig:278" — a hardcoded cross-file line number that will drift on any edit above that line. This is the same drift hazard you already accepted and fixed in this PR for the "line 720" reference in VirtualMachine.zig (commit 93e2313). For consistency, replace with a stable symbolic reference like "in HotReloader.Task.enqueue()".

Extended reasoning...

What the issue is. The new doc-comment on hasAnyHandleWork() (src/jsc/event_loop.zig:591) reads: "Including it closes a narrow race where a thread (e.g. the hot-reloader watcher at hot_reloader.zig:278) pushes to the concurrent queue without bumping concurrent_ref…". The hot_reloader.zig:278 reference is a hardcoded cross-file line number embedded in a doc-comment. Today line 278 is that.reloader.enqueueTaskConcurrent(&that.concurrent_task); inside HotReloader.Task.enqueue(), so the reference is accurate — but it will silently go stale the moment anything is inserted or removed above that line in hot_reloader.zig.

Why this is worth a one-line fix in this PR. This is exactly the same drift hazard that was already flagged and fixed in this very PR. Resolved inline-comment 3187088494 pointed out that "the stale capture at line 720 above" in VirtualMachine.zig would rot, and commit 93e2313 ("comment: refer to the local promise by name, not line number") changed it to "the stale local promise above". The author has demonstrated agreement that hardcoded line numbers in comments are a maintenance hazard worth fixing. Consistency within the same PR argues for the same treatment here — and a cross-file line reference is strictly more brittle than a same-function one, since hot_reloader.zig churns independently of event_loop.zig and there is no "above" hint to fall back on.

Why existing conventions don't excuse it. A grep of src/jsc/*.zig shows this is the only file.zig:NNN cross-file doc-comment reference in the directory, so it is not an established convention being followed — it's a one-off introduced by this PR.

Step-by-step proof of the drift.

1. Today: hot_reloader.zig:278 is that.reloader.enqueueTaskConcurrent(&that.concurrent_task); inside Task.enqueue(). The doc-comment in event_loop.zig:591 says "at hot_reloader.zig:278". Correct.
2. A future PR adds a single field, import, or helper function anywhere in hot_reloader.zig lines 1–277. Every line below shifts down by 1.
3. hot_reloader.zig:278 is now whatever the old line 277 was — perhaps that.next = null; or a closing brace. The doc-comment in event_loop.zig still says "at hot_reloader.zig:278".
4. A reader following the comment opens hot_reloader.zig to line 278, finds something unrelated to enqueueTaskConcurrent, and is left guessing what the "e.g." was supposed to point at.
5. No compiler, linter, or formatter will ever catch this. The comment is never updated because nothing enforces it.

Impact. Purely cosmetic — no runtime effect whatsoever. The reference lives inside an "e.g." parenthetical, so it isn't load-bearing for understanding the function's contract. This should not block the PR.

How to fix. Replace "the hot-reloader watcher at hot_reloader.zig:278" with "the hot-reloader watcher in HotReloader.Task.enqueue()" (or just "the hot-reloader watcher's enqueueTaskConcurrent"). The function name is a stable symbolic anchor that survives line-number churn, and if it's ever renamed, grep/IDE will surface every reference. One-word edit, zero risk.

[robobun]

Closing since #29546 was closed as not-reproducible on 1.3.13 Linux.

The bug IS reproducible — I verified it end-to-end on this branch:

• POSIX: busy-loops at ~100% CPU for the full AbortSignal.timeout duration (from autoTick taking the tickWithoutIdle zero-timeout poll branch)
• Windows: hangs forever (uv_run(UV_RUN_NOWAIT) early-returns when uv__loop_alive() is false, so the unref'd uv timer that drains Bun's own timer heap never fires)

The fix routes loadEntryPoint's TLA wait through a new waitForPromiseOrLoopExit that breaks when nothing in the event loop can progress the promise — matches Node.js semantics. Also closes #14951 (await new Promise(r => {}) same 100% CPU busy-loop).

If the issue gets reopened with a fresh repro, happy to rebase this.