Report unmapped Windows syscall errors with code "UNKNOWN" instead of "EUNKNOWN"

[robobun]

Problem

• On Windows, any syscall failure that resolves to the unknown-errno fallback reaches JS as err.code === "EUNKNOWN" with a message starting EUNKNOWN: unknown error, .... Example: spawning a file CreateProcess refuses (libuv reports UV_UNKNOWN, -4094) through Bun.spawn, Bun.spawnSync, child_process.spawn or child_process.spawnSync.
• node reports code: "UNKNOWN" for the same file (output below), because libuv's name for UV_UNKNOWN is UNKNOWN (uv_err_name, src/uv-common.c); EUNKNOWN exists nowhere in libuv or node. Bun's own util.getSystemErrorName(-4094) (src/errno/lib.rs:52) and process.binding("uv").errname(-4094) (src/jsc/bindings/ProcessBindingUV.cpp:94) also say UNKNOWN, so bun disagreed with itself.
• Cause: bun_sys::Error::get_error_code_tag_name (src/sys/Error.rs:329) uses the strum name of the resolved SystemErrno variant as the code, and to_system_error puts the same string into the message. The Windows enum names that variant EUNKNOWN (src/errno/windows_errno.rs:554). Every other variant's Rust name is already the node spelling (ENOENT, ECHARSET, EOF, EFTYPE, ...); this one is the only mismatch. It is reached by UV_UNKNOWN itself, by translate_uv_error_to_e's fallback for uv codes with no E row, and by the unwrap_or(EUNKNOWN) fallbacks in src/sys/windows/mod.rs and src/sys/lib.rs.

Fix

• #[strum(serialize = "UNKNOWN")] on SystemErrno::EUNKNOWN (the fixing line). The Rust identifier stays, so the existing SystemErrno::EUNKNOWN / E::EUNKNOWN uses are unchanged; only the rendered name changes, and it changes in one place for every path that renders it: err.code, the message prefix, Error::name(), Display for SystemErrno, and the per-crate Error::name() impls.
• Correct because the rendered name is defined by libuv/node, not by the Rust identifier; the same file already does this for E::_2BIG (serialize = "2BIG"). Nothing parses a SystemErrno from a string (no from_str/parse users of the EnumString derive), so the serialize attribute has no other effect. Error::name() already returned the literal "UNKNOWN" when the errno cannot be resolved at all, so the two fallbacks now agree too. POSIX is unaffected: its SystemErrno has no such variant.
• StandaloneModuleGraph.rs formatted this errno with {:?}, which prints the Rust identifier and would have kept saying EUNKNOWN; it now uses {}, which goes through the same strum name as everything else.
• Listener.rs intentionally keeps routing EUNKNOWN through its generic "Failed to listen" error (that variant is also the fallback for unmapped codes, so it does not identify the failure); only its comments changed, since they justified the exclusion by the old spelling.
• src/js/node/child_process.ts:1168 (#handleOnExit, exitCode < 0 branch) is intentionally left alone: that literal is a JS-side err.errno value (its code is ERR_CHILD_PROCESS_UNKNOWN_ERROR), not a rendering of this variant, and the native side never passes a negative exit code (Subprocess::get_exit_code returns the u8 or null; a Status::Err arrives as the err argument), so the branch is not reachable today. Reshaping it to node's errnoException form is a separate change.
• src/js/internal/fs/cp.ts and cp-sync.ts already special-case err.code === "UNKNOWN" (ported from node's Windows readlink workaround); that branch becomes reachable on bun now.
• Verification (all Windows-only tests, it.if(isWindows) / test.skipIf(!isWindows); they fail on the unfixed build and pass with it, checked on windows-x64 with USE_SYSTEM_BUN=1 vs bun bd):
  • test/js/bun/sys/error-name-from-libuv.test.ts: the existing 4094 assertion updated from "EUNKNOWN" to "UNKNOWN", plus a test that Error.name() agrees with util.getSystemErrorName(-4094) and that a uv code with no constant (4000) folds to the same name.
  • test/js/bun/spawn/spawn.test.ts: Bun.spawnSync and Bun.spawn on a non-PE bad.exe throw { code: "UNKNOWN", errno: -4094, message: "UNKNOWN: unknown error, uv_spawn" }.
  • test/js/node/child_process/child_process.test.ts: spawn throws and spawnSync returns { code: "UNKNOWN", errno: -4094 } with node's syscall values; the expected values are node v26.3.0's output for the same file.
  • The garbage bad.exe yields -4094 on both windows-x64 and windows-aarch64 (checked with the released bun on both), so the precondition holds on both Windows CI lanes.
  • Also green with the fix on windows-x64: the full spawn.test.ts and child_process.test.ts files, test/js/node/fs/translate-uv-error-windows.test.ts, rm-windows-ntstatus.test.ts, test/js/bun/net/named-pipe-listen-error.test.ts, test/js/node/util/util.test.js.
• The same repro also shows that Windows spawn errors carry no path (POSIX ones and node do); that is a separate defect in spawn_process_windows and is tracked separately, not changed here.

Background

• bun_sys::Error stores an errno as an E discriminant. On Windows there is no host errno, so bun keeps two parallel #[repr(u16)] enums with identical discriminants: E (bare names, UNKNOWN = 134) for matching in Rust code, and SystemErrno (E-prefixed names, EUNKNOWN = 134) whose variant names double as the node-style error codes shown to users. Win32 and libuv error codes are folded into these tables; anything without a row lands on discriminant 134.
• strum's IntoStaticStr derive turns a variant into its name as a &'static str; #[strum(serialize = "...")] overrides that string for one variant without renaming it.
• UV_UNKNOWN (-4094) is libuv's own "no errno for this" code. node's err.errno is the libuv code and err.code is uv_err_name() of it, which is where UNKNOWN comes from; bun already reports errno: -4094 here, only the name was off.

Repro output (windows-x64)

Fixture: 11 bytes that are not a PE image, written to C:/tmp/bad.exe.

node v26.3.0:

child_process.spawnSync -> { code: "UNKNOWN", errno: -4094, syscall: "spawnSync C:/tmp/bad.exe", path: "C:/tmp/bad.exe" }
child_process.spawn     -> throws { code: "UNKNOWN", errno: -4094, syscall: "spawn" }
util.getSystemErrorName(-4094) -> "UNKNOWN"

bun 1.4.0 canary (before):

Bun.spawnSync           -> { code: "EUNKNOWN", errno: -4094, syscall: "uv_spawn", message: "EUNKNOWN: unknown error, uv_spawn" }
Bun.spawn               -> same
child_process.spawnSync -> { code: "EUNKNOWN", errno: -4094, syscall: "spawnSync C:/tmp/bad.exe" }
child_process.spawn     -> throws { code: "EUNKNOWN", errno: -4094, syscall: "spawn" }
util.getSystemErrorName(-4094) -> "UNKNOWN"

this branch (bun bd):

Bun.spawnSync           -> { code: "UNKNOWN", errno: -4094, syscall: "uv_spawn", message: "UNKNOWN: unknown error, uv_spawn" }
Bun.spawn               -> same
child_process.spawnSync -> { code: "UNKNOWN", errno: -4094, syscall: "spawnSync C:/tmp/bad.exe" }
child_process.spawn     -> throws { code: "UNKNOWN", errno: -4094, syscall: "spawn" }

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 28 minutes

Limit details: You’ve used all 5 included reviews currently available under your plan.

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: 9f12413d-1536-4f4e-ac68-0c6840a5b6e1

📥 Commits

Reviewing files that changed from the base of the PR and between aec33f5 and a1d9c3f.

📒 Files selected for processing (6)

• src/errno/windows_errno.rs
• src/runtime/socket/Listener.rs
• src/standalone_graph/StandaloneModuleGraph.rs
• test/js/bun/spawn/spawn.test.ts
• test/js/bun/sys/error-name-from-libuv.test.ts
• test/js/node/child_process/child_process.test.ts

---

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

[robobun]

Status: reproduced on windows-x64 and windows-aarch64 with the released bun (Bun.spawnSync / child_process.spawnSync on a non-PE .exe give code: "EUNKNOWN", node v26.3.0 gives "UNKNOWN" for the same file). The new Windows-only tests fail with USE_SYSTEM_BUN=1 and pass with bun bd on windows-x64; the full spawn.test.ts and child_process.test.ts files are green with the fix there. Waiting on CI.

[claude]

LGTM — one-line strum serialize override making the Windows unknown-errno fallback render as UNKNOWN (matching libuv/node), plus consistent formatting and Windows-only regression tests. The inline nit about child_process.ts:1168 is pre-existing and on a different mechanism; not blocking.

Extended reasoning...

Overview

The fixing change is one attribute: #[strum(serialize = "UNKNOWN")] on SystemErrno::EUNKNOWN in src/errno/windows_errno.rs. This overrides the string IntoStaticStr/Display/EnumString produce for that variant without renaming the Rust identifier, so every existing SystemErrno::EUNKNOWN / E::EUNKNOWN match arm compiles unchanged. The pattern is already used in the same enum for E::_2BIG → "2BIG". The other source changes are: comment-only rewording in Listener.rs (behavior unchanged — the code already routed EUNKNOWN to a generic error and hardcoded "UNKNOWN" in the fallback), and {:?} → {} in StandaloneModuleGraph.rs so a Windows-only CopyFileW error message renders through the strum name instead of the Rust identifier. Three test files gain Windows-gated coverage (it.if(isWindows) / test.skipIf(!isWindows)).

Security risks

None. This changes only the string rendered for an already-surfaced error variant on Windows. No parsing, validation, auth, or privileged path is touched.

Level of scrutiny

Low-to-medium. It is a targeted Node compat fix with one behavioral line and mechanical follow-ups. I verified: Display for SystemErrno at src/errno/lib.rs:329 delegates to <&'static str>::from (the IntoStaticStr impl), so the {} change in StandaloneModuleGraph.rs compiles and picks up the override; no callers of SystemErrno::from_str/.parse() exist in src/, so the EnumString side of the attribute has no effect; the macro-appended UV_UNKNOWN tail variant serializes as "UV_UNKNOWN", so there is no strum name collision; no remaining "EUNKNOWN" string literals in test/, and the only one in src/ is the pre-existing child_process.ts:1168 site the inline nit already covers.

Other factors

The PR description documents USE_SYSTEM_BUN=1 fail / bun bd pass on windows-x64, cross-checks the bad.exe fixture on both Windows arches, and lists the adjacent test files re-run green. The tests assert exact {code, errno, syscall, message} shapes against node v26 output, cover both Bun.spawn/spawnSync and child_process.spawn/spawnSync, and add a self-consistency check against util.getSystemErrorName(-4094). The one existing assertion changed (error-name-from-libuv.test.ts line 20) is the direct assertion on the previously-wrong name, correctly updated. The inline nit is non-blocking: it is a different field (err.errno as a string), a different mechanism (JS SystemError constructor, not the strum table), and its correct fix is orthogonal (numeric errno + getSystemErrorName).

[robobun]

Heads up on an interaction with #39345, which makes spawn_process_windows attach argv[0] to uv_spawn errors the way the POSIX path already does. Once that lands, the message for the bad.exe case here becomes UNKNOWN: unknown error, uv_spawn '<path to bad.exe>', so the exact message: "UNKNOWN: unknown error, uv_spawn" expected in the new spawn.test.ts case will stop matching. Asserting code/errno only (as the child_process.test.ts case here already does), or matching the UNKNOWN: unknown error, uv_spawn prefix, would keep it passing in either merge order. The two branches merge cleanly otherwise, and the tests in #39345 do not depend on the code name.

[robobun]

Heads-up from the errno dedupe: #40720 is on main (bd630c1). It adds an EUNKNOWN variant to the three POSIX enums as the fallback for a kernel errno outside the table (src/errno/linux_errno.rs:157 = 134, darwin_errno.rs:127 = 107, freebsd_errno.rs:118 = 98). Its test (test/js/node/fs/fs-stat-seccomp-linux.test.ts, "a code above the table reports EUNKNOWN") asserts code: "EUNKNOWN" and message: "EUNKNOWN: unknown error, fsync" on Linux.

So "POSIX is unaffected" in the description no longer holds. If this rename is the chosen spelling, the three POSIX variants want the same #[strum(serialize = "UNKNOWN")] so an unmapped code renders the same on every platform, and that test's two expected strings change to UNKNOWN. The branch still merges cleanly, so this is a content update, not a conflict.