no-orphans(windows): allow CREATE_BREAKAWAY_FROM_JOB and set DIE_ON_UNHANDLED_EXCEPTION on the Job

[robobun]

What

ParentDeathWatchdog::enable() on Windows creates a Job Object for --no-orphans and self-assigns Bun into it, so it becomes the immediate job for every descendant. It set only JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE.

Why it matters

Two observable problems:

1. CreateProcess(CREATE_BREAKAWAY_FROM_JOB) fails. Any descendant that passes that flag gets ERROR_ACCESS_DENIED because the immediate job does not permit breakaway. On a Windows 2019 box against current main:

   with --no-orphans:  LimitFlags=0x2000, CreateProcessW(BREAKAWAY) ok=0 err=5
   without:            CreateProcessW(BREAKAWAY) ok=1
   

   That is a hard spawn failure --no-orphans should not cause. libuv's own comment on its global job notes the same hazard.

2. WER can park a crashed descendant. A non-Bun child that crashes with no top-level filter reaches UnhandledExceptionFilter's default path (WER dialog / JIT debugger prompt), which on a headless box blocks forever. JOB_OBJECT_LIMIT_DIE_ON_UNHANDLED_EXCEPTION makes it exit with the NTSTATUS instead.

Fix

Set LimitFlags = KILL_ON_JOB_CLOSE | DIE_ON_UNHANDLED_EXCEPTION | BREAKAWAY_OK.

Why this is safe for Bun itself: Bun's crash reporter is installed via SetUnhandledExceptionFilter (handle_unhandled_exception_windows in src/crash_handler/lib.rs). That callback runs before the Job flag applies; crash_handler() is -> !. The flag only changes the behavior for exception codes Bun's classifier declines and for non-Bun descendants, both of which should terminate rather than prompt under --no-orphans.

Why not SILENT_BREAKAWAY_OK: libuv's global job sets it because libuv explicitly assigns each child, so grandchildren intentionally escape. The --no-orphans Job relies on inheritance to cover the whole descendant tree; SILENT_BREAKAWAY_OK would make every child escape and break the feature. The existing "cmd.exe-spawned descendant" tests already rely on this.

Applied the same flag set to the parallel test runner's kill-on-close Job in Coordinator.rs (same shape, same failure modes).

Verification

New test in test/cli/run/no-orphans.test.ts probes the immediate Job's LimitFlags via QueryInformationJobObject(NULL) and exercises CreateProcess(CREATE_BREAKAWAY_FROM_JOB) via FFI.

fail-before (canary on Windows Server 2019)

error: expect(received).toEqual(expected)
  {
-   "BREAKAWAY_OK": true,
-   "DIE_ON_UNHANDLED_EXCEPTION": true,
+   "BREAKAWAY_OK": false,
+   "DIE_ON_UNHANDLED_EXCEPTION": false,
    "KILL_ON_JOB_CLOSE": true,
    "SILENT_BREAKAWAY_OK": false,
    "qok": 1,
  }
(fail) windows: --no-orphans Job allows breakaway and sets DIE_ON_UNHANDLED_EXCEPTION, not SILENT_BREAKAWAY

pass-after (`bun bd test` on Windows Server 2019)

(pass) windows: --no-orphans Job allows breakaway and sets DIE_ON_UNHANDLED_EXCEPTION, not SILENT_BREAKAWAY [571.10ms]
 10 pass
 14 skip
 0 fail

The src/ change is entirely #[cfg(windows)] and the test is skipIf(!isWindows), so a Linux-only gate cannot observe fail-before; the evidence above was captured on windows-x64.

---

no test proof · iteration 1 · Platform-specific test(s) that do not run on this machine. Deferring to CI, which covers all platforms: test/cli/run/no-orphans.test.ts

[github-actions]

Found 1 issue this PR may fix:

1. Windows: Bun.spawn({ detached: true }) child is killed when the parent exits (does not outlive the parent) #31603 - Reports that Bun.spawn({ detached: true }) children are killed when parent exits on Windows because the --no-orphans Job Object doesn't permit CREATE_BREAKAWAY_FROM_JOB. This PR adds JOB_OBJECT_LIMIT_BREAKAWAY_OK which directly fixes that.

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

Fixes #31603

🤖 Generated with Claude Code

[coderabbitai]

Walkthrough

Changes

Windows Job Object configurations now include exception termination and process breakaway flags. A Windows-only --no-orphans test probes these flags and verifies that breakaway process creation succeeds.

Windows Job Object behavior

Layer / File(s)	Summary
Windows Job Object flag configuration src/io/lib.rs, src/runtime/cli/test/parallel/Coordinator.rs	Job Objects now set KILL_ON_JOB_CLOSE, DIE_ON_UNHANDLED_EXCEPTION, and BREAKAWAY_OK.
--no-orphans Windows validation test/cli/run/no-orphans.test.ts	The test checks Job Object flags, rejects SILENT_BREAKAWAY_OK, verifies breakaway process creation, and confirms successful Bun exit.

Suggested reviewers: jarred-sumner

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
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.
Title check	✅ Passed	The title accurately summarizes the Windows Job Object flag change and breakaway behavior.
Description check	✅ Passed	The description covers the change, motivation, and verification steps, and is mostly complete despite using different headings.

---

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

[coderabbitai]

Caution

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

⚠️ Outside diff range comments (1)

src/io/lib.rs (1)

106-148: 📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win

Extract the shared Windows Job Object flags into one constant. src/io/lib.rs:131-133 and src/runtime/cli/test/parallel/Coordinator.rs:738-740 both spell the same KILL_ON_JOB_CLOSE | DIE_ON_UNHANDLED_EXCEPTION | BREAKAWAY_OK mask. Hoist it into a shared pub const and reference it from both sites to avoid silent drift if the policy changes.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/io/lib.rs` around lines 106 - 148, Extract the shared Windows Job Object
limit mask into a public constant, then replace the inline flag expression in
src/io/lib.rs:106-148 and the matching expression in
src/runtime/cli/test/parallel/Coordinator.rs:722-753 with that constant. Define
it in an appropriate shared Windows-accessible module and preserve the existing
KILL_ON_JOB_CLOSE, DIE_ON_UNHANDLED_EXCEPTION, and BREAKAWAY_OK policy.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@src/io/lib.rs`:
- Around line 106-148: Extract the shared Windows Job Object limit mask into a
public constant, then replace the inline flag expression in
src/io/lib.rs:106-148 and the matching expression in
src/runtime/cli/test/parallel/Coordinator.rs:722-753 with that constant. Define
it in an appropriate shared Windows-accessible module and preserve the existing
KILL_ON_JOB_CLOSE, DIE_ON_UNHANDLED_EXCEPTION, and BREAKAWAY_OK policy.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: c5e8e6f8-99b5-4a7c-a451-dfa9109a66bc

📥 Commits

Reviewing files that changed from the base of the PR and between e61c15e and 44f75af.

📒 Files selected for processing (3)

• src/io/lib.rs
• src/runtime/cli/test/parallel/Coordinator.rs
• test/cli/run/no-orphans.test.ts

[robobun]

Addressed in 4d8f022:

• coderabbit (shared constant): hoisted into bun_sys::windows::JOB_LIMIT_FLAGS_KILL_TREE_ON_CLOSE with the rationale on the constant's doc comment, and both call sites now reference it.
• claude (FFI HANDLE type): good catch; changed the fixture's WaitForSingleObject/CloseHandle HANDLE args to FFIType.u64 so the getBigUint64 values round-trip (matches test/js/bun/windows/appcontainer.test.ts). The assertions were unaffected; this was cleanup-path only.

On the find-issues bot suggestion: this PR does not fix #31603. That issue reproduces without --no-orphans (verified on Windows Server 2019: the detached helper dies with or without this patch, with or without --no-orphans). Bun.spawn({detached: true}) goes through libuv, which deliberately does not pass CREATE_BREAKAWAY_FROM_JOB for UV_PROCESS_DETACHED, so BREAKAWAY_OK on the --no-orphans job wouldn't help even when it is active. Not adding the Fixes line.

CI on 44f75af: the only [new] failure was worker-transfer-terminate-stress.test.ts (JSC !exception() assertion on linux x64-asan), which this diff cannot reach: every src/ change here is under #[cfg(windows)]. Reported separately; the rest were [flaky] and passed on retry.

[claude]

No bugs found; the earlier FFI HANDLE-type nit was addressed in 4d8f022. Deferring to a maintainer only because this is a semantic policy change to --no-orphans on Windows — BREAKAWAY_OK lets descendants that explicitly pass CREATE_BREAKAWAY_FROM_JOB escape the kill-on-close Job, and DIE_ON_UNHANDLED_EXCEPTION changes WER/crash behavior for every descendant in the Job. The reasoning looks sound and matches standard practice (libuv, Chromium), but it's worth a human confirming the trade-off.

What was reviewed:

• Verified the flag bit values (0x2000/0x400/0x800) match winnt.h and the shared constant is used at both inheritance-based Job sites; become_watcher_manager's Job correctly stays separate (it uses SILENT_BREAKAWAY_OK + explicit PROC_THREAD_ATTRIBUTE_JOB_LIST assignment, different model).
• Checked the test's FFI struct offsets/sizes (JOBOBJECT_EXTENDED_LIMIT_INFORMATION=144, LimitFlags@16, STARTUPINFOW=104, PROCESS_INFORMATION=24) against x64 layout.
• Confirmed the existing "cmd.exe-spawned descendant is reaped" tests still guard against SILENT_BREAKAWAY_OK regressions.

Extended reasoning...

Overview

Adds two Win32 Job Object limit flags (JOB_OBJECT_LIMIT_BREAKAWAY_OK, JOB_OBJECT_LIMIT_DIE_ON_UNHANDLED_EXCEPTION) to the kill-on-close Jobs created by ParentDeathWatchdog::enable() (--no-orphans) and the parallel-test Coordinator. Hoisted into a shared pub const JOB_LIMIT_FLAGS_KILL_TREE_ON_CLOSE in src/sys/windows/mod.rs with a doc comment explaining why SILENT_BREAKAWAY_OK is deliberately omitted. A Windows-only test in test/cli/run/no-orphans.test.ts probes LimitFlags via QueryInformationJobObject(NULL) and behaviorally verifies CreateProcess(CREATE_BREAKAWAY_FROM_JOB) succeeds. Net src/ delta: one 3-flag constant + two one-line call-site swaps, all under #[cfg(windows)].

Security risks

None identified. The change loosens the Job's containment only for children that explicitly pass CREATE_BREAKAWAY_FROM_JOB — the same contract every other kill-on-close Job in the ecosystem offers. DIE_ON_UNHANDLED_EXCEPTION terminates crashed descendants instead of leaving them parked on a WER prompt; no new attack surface.

Level of scrutiny

Moderate. The code change is trivially correct (flag OR into an existing DWORD), but it alters the observable semantics of an opt-in runtime feature: (1) descendants can now escape --no-orphans by explicit breakaway, and (2) any descendant's unhandled exception now terminates rather than reaching WER. Both are defensible and well-argued in the PR body (fixes a hard ERROR_ACCESS_DENIED compat break; prevents headless-CI hangs), and the crash-reporter interaction is analyzed (Bun's own SetUnhandledExceptionFilter runs first, crash_handler() is -> !). Still, it's a user-facing policy trade-off on Windows that a maintainer should sign off on rather than a bot.

Other factors

• Sibling coverage: grepped for other JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE sites. The third site, become_watcher_manager(), already sets BREAKAWAY_OK | SILENT_BREAKAWAY_OK | DIE_ON_UNHANDLED_EXCEPTION and assigns children via PROC_THREAD_ATTRIBUTE_JOB_LIST, so the new inheritance-based constant intentionally does not apply there. The two changed sites are the complete set of inheritance-based Jobs.
• Regression guard: the pre-existing "cmd.exe-spawned descendant" tests in the same file rely on Job-membership inheritance, so they would fail if someone later added SILENT_BREAKAWAY_OK; the new test additionally asserts that bit is clear.
• Prior feedback: my earlier nit (BigInt→FFIType.ptr producing garbage handles in the fixture's cleanup path) was fixed by switching to FFIType.u64; comment-cop feedback on doc length was addressed. All threads resolved.
• Fail-before/pass-after evidence was captured on Windows Server 2019 (Linux CI can't observe the change since everything is #[cfg(windows)] / skipIf(!isWindows)).

[robobun]

^{Updated 6:57 PM PT - Jul 29th, 2026}

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

• test/js/node/worker_threads/worker-transfer-terminate-stress.test.ts - SIGABRT on 🐧 13 x64-asan

---

🧪   To try this PR locally:

bunx bun-pr 36414

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

bun-36414 --bun

[claude]

LGTM — the prior FFI HANDLE-type feedback is addressed (FFIType.u64), and the src/ change is now a single shared constant referenced from both call sites.

What was reviewed:

• Verified the Win32 flag values (0x2000/0x400/0x800/0x1000) and CREATE_BREAKAWAY_FROM_JOB=0x01000000 against winnt.h.
• Checked the FFI struct offsets in the probe fixture: LimitFlags at offset 16, sizeof(JOBOBJECT_EXTENDED_LIMIT_INFORMATION)=144, sizeof(STARTUPINFOW)=104, sizeof(PROCESS_INFORMATION)=24 on x64.
• Confirmed become_watcher_manager() was correctly not switched to the new constant (it uses explicit assignment via PROC_THREAD_ATTRIBUTE_JOB_LIST, so SILENT_BREAKAWAY_OK is right there).
• Confirmed omitting SILENT_BREAKAWAY_OK here keeps the existing "cmd.exe-spawned descendant" tests valid.

Extended reasoning...

Overview

Windows-only behavioral tweak to the Job Object LimitFlags used by --no-orphans (src/io/lib.rs) and the parallel-test coordinator (src/runtime/cli/test/parallel/Coordinator.rs). Previously both set only KILL_ON_JOB_CLOSE; now they OR in DIE_ON_UNHANDLED_EXCEPTION | BREAKAWAY_OK via a new shared pub const JOB_LIMIT_FLAGS_KILL_TREE_ON_CLOSE in src/sys/windows/mod.rs. A new Windows-only test in test/cli/run/no-orphans.test.ts probes the immediate Job's flags via QueryInformationJobObject(NULL) and behaviorally verifies CreateProcess(CREATE_BREAKAWAY_FROM_JOB) succeeds. Net src/ delta: +8/-2, all under #[cfg(windows)].

Security risks

None. This is Win32 Job Object flag configuration for process-tree cleanup. BREAKAWAY_OK slightly weakens the --no-orphans guarantee (a descendant that explicitly passes CREATE_BREAKAWAY_FROM_JOB escapes), but that's the documented Win32 semantics for explicit opt-out, and the alternative is a hard ERROR_ACCESS_DENIED spawn failure that --no-orphans should not cause. SILENT_BREAKAWAY_OK — which would defeat the feature — is deliberately excluded, documented on the constant, and asserted-false in the test.

Level of scrutiny

Low-medium. The src/ change is a 3-flag bitmask constant with two one-line call-site swaps. The PR description gives a clear mechanistic account of both problems (breakaway spawn failure with err=5; WER parking a crashed descendant on headless boxes) with before/after evidence on Windows Server 2019, and explains why DIE_ON_UNHANDLED_EXCEPTION doesn't interfere with Bun's own crash reporter (SetUnhandledExceptionFilter runs first, crash_handler() is -> !). The reasoning for excluding SILENT_BREAKAWAY_OK (inheritance-based membership vs. libuv's explicit-assignment model) is consistent with the existing become_watcher_manager() job, which does use explicit assignment and was correctly left untouched.

Other factors

• I previously flagged that the test fixture passed BigInt handles through FFIType.ptr; that was fixed in 4d8f022 (now FFIType.u64, matching appcontainer.test.ts). All review threads are resolved.
• The comment-cop bot flagged the constant's doc comment; the author's response (durable rationale on a pub const, not a workaround justification) is reasonable per REVIEW.md's "comments carry only durable non-obvious content" — omitting SILENT_BREAKAWAY_OK vs. libuv is exactly the kind of deliberate deviation worth recording.
• The test asserts both the flag bits (structured object diff for readable failure) and the behavioral CreateProcess result, plus SILENT_BREAKAWAY_OK: false to guard against a future regression that would silently break the existing inheritance tests.
• Fail-before/pass-after evidence was captured on Windows; the change cannot be observed on Linux CI, so Windows CI is the gate.

[robobun]

CI summary across builds 85519 / 85526 / 85546: the new Windows test passed on every Windows lane in every run. Remaining red is unrelated to this diff (every src/ line here is under #[cfg(windows)] and the added test is skipIf(!isWindows)):

• test/js/node/worker_threads/worker-transfer-terminate-stress.test.ts [new]: JSC !exception() assertion SIGABRT on debian x64-asan. Reported separately for main.
• test/cli/run/no-orphans.test.ts [flaky] on darwin 14 x64: the pre-existing bun run --no-orphans (perl): fast-exit intermediate test timed out once and passed on retry. That test is skipIf(!isPosix), untouched by this PR, and is the subject of test(no-orphans): skip fast-exit perl daemon test on macOS #36413.
• Everything else is [flaky] (passed alone or on retry) in areas this PR does not touch.

Ready for review.