[cirospaciari]

Ports the Node v26.3.0 worker-related upstream tests that were still missing and fixes the node:worker_threads behaviour they expose. Ten upstream files are added, byte-identical to upstream, with no expectations.txt or sanitizer exemptions; each is enabled by one of the fixes below.

upstream test	fix that enables it
test-diagnostics-channel-worker-threads.js	worker_threads diagnostics channel
test-worker-hasref.js	async_hooks WORKER resource
test-worker-error-stack-getter-throws.js	error clone survives a throwing stack getter
test-perf-hooks-worker-timeorigin.js	process-wide performance.timeOrigin
test-worker-internal-modules.mjs	error.code survives non-cloneable errors
test-tls-get-ca-certificates-worker-{,no-}use-system-ca.js	per-thread --use-system-ca
sequential/test-cpu-prof-dir-worker.js, sequential/test-cpu-prof-worker-argv.js	--cpu-prof in workers
sequential/test-worker-eventlooputil.js	real eventLoopUtilization() (this test previously hung, so it could not be vendored)

(A first batch of tests that already passed — http2-stream-terminate, unsupported-eval-on-url, cleanup-handles, dispose, and the -pe alias with test-preload-worker — landed on main separately while this was open and is no longer part of this diff.)

Behaviour fixes

worker_threads diagnostics channel (worker_threads.ts). Node publishes the new Worker on the worker_threads channel at the end of the constructor; Bun never did. The channel is resolved at module load, not lazily: diagnostics_channel uses Map internally (a lazy require picks up user tampering — it broke the "tampered Map prototype" test), and dc's registry is a WeakRefMap whose subscribe() swaps the prototype in place, so a module-load strong ref is what keeps the published channel from being re-created underneath the publisher. Verified against the node binary: identical payload, one publish per Worker, none without subscribers, nested workers publish on their own thread's channel.

async_hooks WORKER resource (worker_threads.ts, async_hooks.ts, async_hooks_tick.ts). init was only ever delivered for TickObject, so hooks looking for WORKER (what why-is-node-running relies on) never fired. The Worker constructor now emits one; hasRef() follows ref()/unref() and reads back undefined once the thread has exited, ref()/unref() no-op after exit, a throwing init hook is fatal as in node. Found on the way: createHook invoked init bare, so this.disable() inside it threw — node calls it as a method on the hook.

Worker error clone survives a throwing Error.prepareStackTrace (Worker.cpp). Cloning reads stack; a throwing getter took the whole clone down and the parent got pretty-printed text in message. Node drops just the unreadable stack; the clone is retried once with an own undefined stack, only on the failure path and via setStackPropertyAlreadyMaterialized() so the getter can't run again.

performance.timeOrigin is process-wide (VirtualMachine.rs). Each worker VM took its own Instant::now(), so a worker's origin drifted by the spawn delay (264 ms measured vs node's 0). Every thread now reports the process origin; Bun.nanoseconds() becomes "since the process started" as documented.

error.code survives a non-cloneable thrown value. A worker throwing something structured clone can't serialize fell back to message text and the parent rebuilt a bare Error, losing code — Bun's own ResolveMessage (ERR_UNKNOWN_BUILTIN_MODULE) is exactly that. code is carried alongside the message; the message text is unchanged byte for byte.

'online' fires at node's timing (WorkerMessagingProxy.cpp, web_worker.rs). Bun posted online only after the entry point's promise settled, so a worker whose top level never returns (while(true)) never reported online and terminate() on it never resolved. dispatchOnline did two separable things — the Pending→Running state flip that also gates message routing, and posting the event — and moving both regresses message-routing, heap-profile and destruction tests (measured; details in the discussion below). Only the event moves: it is posted before the entry loads, the state flip stays where it was. Consequences that fall out: a worker whose entry throws or fails to resolve reports online then error like node; the bun-API Web Worker's 'open' likewise now precedes the entry point (pinned by a test in worker.test.ts).

MessagePort listeners get the port as this — injectFakeEmitter's wrapper dropped the receiver. BroadcastChannel#ref()/unref() return the channel as in node instead of undefined. process.execArgv treats a node whole-token alias such as -pe as value-taking only ahead of the script name, so bun run -pe script.js no longer swallows the script.

--cpu-prof profiles worker threads (web_worker.rs, BunCPUProfiler.rs, jsc_hooks.rs). Node writes one profile per thread and honours a Worker's own execArgv; Bun configured the profiler on the main-thread run path only, so a process with a worker wrote one profile and execArgv: ['--cpu-prof'] did nothing. Inheritance follows node_worker.cc: no execArgv inherits the parent's settings, an explicit list (even []) replaces them, and a worker's own --cpu-prof, --cpu-prof-md, --cpu-prof-dir, --cpu-prof-name and --cpu-prof-interval are honoured, including flags that follow another option's separate value. Default file names carry the real thread id (CPU.<date>.<time>.<pid>.<threadId>.<seq>; the main thread's 0 segment is what it always was), so concurrent threads don't collide; a custom --cpu-prof-name still collides across threads, as node's does. Also fixed on the way: the sampling interval was a thread_local, so workers silently sampled at the 1000 µs default (312 → 1529 samples at --cpu-prof-interval 100), and an interval that fits u32 but not c_int panicked — it clamps.

performance.eventLoopUtilization() (perf_hooks.ts, internal/perf/event_loop_utilization.ts, usockets loop_data.h/epoll_kqueue.c/loop.c, VirtualMachine.rs, web_worker.rs) was hardcoded zeros, and worker.performance.eventLoopUtilization() a stub. The loop already brackets its park, so idle accounting is two clock reads on ticks that were going to sleep anyway; Windows uses libuv's uv_metrics_idle_time (UV_METRICS_IDLE_TIME, which node enables unconditionally). Semantics match node's: the main thread reports zeros until its loop first runs (an entry point's synchronous top level sees {0,0,0}; the time spent in a top-level await counts), a worker counts from before its script starts, and a worker's ELU is readable from the parent. Elapsed and idle come from the same clock (they diverged across sleep on macOS), idle accumulated before the loop is considered started is not charged (bun run holds the stamp back while the entry graph loads, since an import transpiles off-thread and the loop parks for it, and lets it through once the entry root is evaluating, via the existing entry_evaluation_started signal, so a top-level await still counts), and the mid-park counter is published through a seqlock so a reader never sees a torn idle/entry pair — the shared math lives in internal/perf/event_loop_utilization as node's does, including the deliberately unguarded NaN for two identical samples.

Two traps for anyone touching this: us_internal_loop_data_t is us_loop_t's first member and is mirrored in Rust (src/uws_sys/InternalLoopData.rs) — adding a field without the mirror shifts num_polls and the loop silently stops parking; and a counter folded in only when a park ends reads stale mid-park, which libuv solves the same way (publish the park's entry time).

--use-system-ca is a per-thread (per-Environment) option (web_worker.rs, VirtualMachine.rs, Arguments.rs, jsc_hooks.rs, SSLConfig.rs, ssl_config.rs, fetch.rs, usockets openssl.c/root_certs.cpp/quic.c, tls.ts). Previously a Worker's execArgv was ignored for everything but --no-addons, --no-use-system-ca did not exist, and the CA decision was a process-global boolean read by a process-wide cached store. Now:

• Resolution follows node_worker.cc: a thread starts from its parent's resolved decision, a custom env re-derives it from that env's NODE_USE_SYSTEM_CA, and flags win — its own execArgv's, or the parent's flags when it has none. The main thread's inheritable value is flag-only (the env var is not promoted into a flag). --no-use-system-ca is accepted on the CLI, in execArgv and in NODE_OPTIONS.
• The decision reaches every context a thread creates: tls/net client and server contexts, the default client context fetch uses, and WebSocket. Default stores are built once per decision and shared; a thread whose decision differs from the process default gets its own default client context (and Bun.serve without TLS options stays plain HTTP in such a thread).
• The store is main's (tls: embed root CAs as DER and parse them lazily, SIMD base64 for certificate PEM, bump BoringSSL #40862): the bundled roots, OpenSSL's default paths (SSL_CERT_FILE / the hash directory), and NODE_EXTRA_CA_CERTS in every mode, plus the OS store when the thread asked for it (on Linux the OS store is the Rust system loader, which also reads every regular file in SSL_CERT_DIR; on macOS/Windows it is the OS store alone); --use-openssl-ca selects OpenSSL's default lookups instead of the bundled roots and ignores the OS store, as NewRootCertStore does. tls.getCACertificates('default') reports the same rules, per thread.
• ⚠️ When comparing against node, unset NODE_EXTRA_CA_CERTS — with it set, real node fails the two upstream tests exactly like an unfixed bun.

Known gaps / notes

• The HTTP/3 client context is a process-lifetime singleton on the HTTP thread and is built with the process default store, so a Worker's own --use-system-ca / --no-use-system-ca does not reach its H3 connections (H1/H2, tls, and WebSocket in the same worker do follow it). Per-thread H3 would need per-connection context selection; same bucket as the SQL and S3 seeds noted in the comments.
• --use-openssl-ca combined with --use-system-ca is rejected by the CLI, where node accepts the pair (openssl wins); pre-existing.
• A Worker whose custom env omits NODE_USE_SYSTEM_CA while the process env sets it follows the parent's decision (node re-derives from the custom env → bundled only). Documented corner.
• hasRef() reads back true after terminate() until the exit is delivered — the ref is held on purpose so 'exit' is observed; node reads back undefined sooner.
• Terminating a worker while it is still loading its modules can trip a pre-existing ASSERTION FAILED: !scope.exception() || !result (objectConstructorDefineProperty via the worker preload) on debug/asan builds — the same failure the already-vendored test-worker-message-port-transfer-terminate.js shows on x64-asan. test-worker-vm-context-terminate and test-worker-abort-on-uncaught-exception-terminate, which the online fix would otherwise enable, are left out for that reason; the behaviour is covered by a Bun-side test that avoids the window.
• Native warning output (process.emitWarning, deprecation and unhandled-rejection warnings) inside a Worker still goes to the parent's real fd 2 rather than the worker's piped stderr (node routes it to w.stderr); JS console.* is routed correctly. Rerouting emitWarning through console.error would change main-thread warning formatting, so the fix is routing the native console client at the worker's stdio — left for a separate change. Related: process.listenerCount('warning') is 0 (node 1) and a user 'warning' listener suppresses the default print.
• Bun's async_hooks implements AsyncLocalStorage/AsyncResource only; MESSAGEPORT resources (test-worker-messageport-hasref, …-inspect-during-init-hook) remain out of scope. Also still missing from the vendored set: execArgv validation (ERR_WORKER_INVALID_EXEC_ARGV), resourceLimits, moveMessagePortToContext, data: URL MIME handling, process.env defineProperty semantics.

Found via the asan shard, not fixed here

1. terminate() with an in-flight dns.lookup is a use-after-free (Linux only — the lib_c path): GlobalData::drop tears the Resolver down while in-flight lookups still hold an IntrusiveRc. test-worker-dns-terminate.js was removed from this PR rather than suppressed; it needs a teardown fix in dns.rs.
2. Work landing on a terminating worker after its shutdown drain is a UAF, not just a leak. markTerminating only serializes postTaskTo; the work pool and JSC's DeferredWorkTimer enqueue directly onto concurrent_tasks, the worker thread is detached rather than joined, and the VM box is freed raw — so draining later only narrows the window (tried and discarded; it also frees the node but not the payload). The durable fix is at the poster side (drain-and-join, or a refcount taken by posters). Both sequential/test-worker-fshandles-*-on-termination.js expose it and are left out; the same class covers a lot of test/no-validate-leaksan.txt and the already-failing "cross-thread MessagePort post during worker shutdown" case in worker_threads.test.ts.

Why online was moved the way it was

Moving the whole dispatchOnline (state flip + event) before evaluation regressed six routing tests (enqueueToWorker buffers only while not Running, so postMessage from an 'online' handler drained into a worker with no listener yet); gating delivery on an entry-evaluated flag fixed those but the early Running flip alone still broke heap-profile, terminate-unrefed and two destruction tests. Running is overloaded three ways (online / deliverable / bookkeeping-valid), which is why only the event is posted early here and the flip is untouched. The removed comment claiming a parent online handler calling getHeapSnapshot() would see ERR_WORKER_NOT_RUNNING was wrong — postTaskToWorkerGlobalScope queues on Pending; confirmed by running it.

---

no test proof · iteration 51 · platform-specific test(s) that do not run on this machine, deferring to CI, which covers all platforms: test/js/node/tls/test-use-system-ca.test.ts, test/js/node/process/process.test.js, test/cli/run/cpu-prof.test.ts

[robobun]

^{Updated 12:43 AM PT - Sep 8th, 2026}

❌ @robobun, your commit 94cb78e has 1 failures in Build #112488 (All Failures):

• test/js/node/test/parallel/test-crypto-dh-leak.js - code 1 on 🐧 13 x64-asan

---

🧪   To try this PR locally:

bunx bun-pr 34424

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

bun-34424 --bun

[cirospaciari]

@robobun adopt

[cirospaciari]

@robobun fix conflicts

[robobun]

This branch last merged main at 94cb78e on Sep 8. It now conflicts with main in 22 files (660 commits behind), so it needs a merge before a review. Main has since taken one piece of it (#41383, online before the entry point). The other changes and the ten upstream tests are not on main.

The question for Ciro about the default root store is still open (#34424 (comment)). Comment here when you want the branch brought up to date with main, and I will do it.

[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

Changes

Worker runtime compatibility

Layer / File(s)	Summary
Async hooks and worker state src/js/node/async_hooks.ts, src/js/node/worker_threads.ts, src/js/internal/async_hooks_tick.ts, test/js/node/test/parallel/test-diagnostics-channel-worker-threads.js, test/js/node/test/parallel/test-worker-hasref.js	WORKER init hooks, diagnostics-channel publication, and hasRef() lifecycle tracking are implemented and tested.
Shared timing origin src/jsc/VirtualMachine.rs, test/js/node/test/parallel/test-perf-hooks-worker-timeorigin.js	Virtual machines use a process-wide timing origin, with matching worker and parent time-origin coverage.
Online-event ordering src/jsc/bindings/webcore/Worker.h, src/jsc/bindings/webcore/Worker.cpp, src/jsc/web_worker.rs, test/js/node/worker_threads/worker_threads.test.ts	The worker emits online before loading its entry point while retaining the later running-state transition.
Error and lifecycle handling src/jsc/bindings/webcore/Worker.cpp, test/js/node/test/parallel/test-worker-error-stack-getter-throws.js, test/js/node/test/parallel/test-worker-cleanup-handles.js, test/js/node/test/parallel/test-worker-dispose.mjs, test/js/node/test/parallel/test-worker-http2-stream-terminate.js, test/js/node/test/parallel/test-worker-unsupported-eval-on-url.mjs	Error serialization retries after clearing an invalid stack, and worker cleanup, disposal, termination, and eval validation are covered.

BroadcastChannel reference chaining

Layer / File(s)	Summary
Chained ref operation src/jsc/bindings/webcore/JSBroadcastChannel.cpp	BroadcastChannel.prototype.ref() returns the wrapper after incrementing its reference count.

Node CLI short aliases

Layer / File(s)	Summary
Short-alias parsing contract src/clap/lib.rs, src/clap/streaming.rs, src/clap/comptime.rs	Clap carries configured short aliases and rewrites matching tokens before flag classification.
Node alias wiring src/runtime/cli/Arguments.rs, src/runtime/node/node_process.rs, src/install/PackageManager/CommandLineArguments.rs	The -pe alias maps to -p for auto and run-as-node parsing, with default parser options applied elsewhere.

Worker CPU profiling

Layer / File(s)	Summary
Worker exec-argv contract src/jsc/VirtualMachine.rs, src/runtime/jsc_hooks.rs	Worker exec-argv parsing returns addon and CPU profiling options through a structured hook result.
Profiler inheritance and filenames src/jsc/BunCPUProfiler.rs, src/runtime/cli/run_command.rs	Profiler configuration is inherited by workers, includes thread identifiers, clamps intervals, and produces worker-specific filenames.
Worker profiler integration src/jsc/web_worker.rs, test/js/node/test/sequential/test-cpu-prof-dir-worker.js, test/js/node/test/sequential/test-cpu-prof-worker-argv.js	Worker startup applies profiling options and regression tests validate generated profiles.

Possibly related PRs

• oven-sh/bun#32628: Related diagnostics-channel plumbing for worker_threads.
• oven-sh/bun#33956: Overlaps in Worker::dispatchErrorWithValue.
• oven-sh/bun#34208: Related worker_threads diagnostics-channel publication.

Suggested reviewers: robobun

🚥 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 worker_threads compatibility changes and added tests. It is longer and more detailed than recommended, but it remains specific and related to the primary changes.
Description check	✅ Passed	The description provides a detailed summary of the changes, verification context, known gaps, and test coverage. It does not use the template headings exactly, but it contains the required information…

---

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

[cirospaciari]

@robobun heads-up — I resolved the conflicts locally, so you can drop your run to avoid a race. Your resolution started from c308af4b6b, but I pushed f1384cda99 (the 'online' timing fix) right after, so a merge built on the older head would drop it.

What conflicted and how I resolved it, in case it's useful: only src/js/node/worker_threads.ts, three hunks, all where #34338 and my changes touch the same lines. #34338 removed the #stdoutAutoPipe/#stderrAutoPipe fields and dropped the stdio port ref/unref out of ref()/unref() (ports now manage their own ref via incrementsPortRef). My side only ever added #hasRef bookkeeping there, so I took main's structure wholesale and kept just the two if (!this.#exited) this.#hasRef = ... lines plus the field. async_hooks.ts (#31825) and VirtualMachine.rs (#34293, #32498) auto-merged.

I verified the merge is a pure addition on top of main — git diff origin/main -- src/js/node/worker_threads.ts shows zero deleted lines, so nothing from #34338 or #31825 is reverted.

Also: #34338 fixed the {stdout:true} hang I'd documented in this PR's description as an open bug, so I'm dropping that section. Worth noting your fix got the part mine missed — I tried attaching the listener eagerly and it regressed ~20 tests because the listener re-refs the port; port.unref() immediately after the eager attach is the piece I didn't have.

[claude]

All five earlier findings are addressed in d7e1659 (test-worker-memory dropped, init/dc order swapped, #hasRef seeded from options.ref, async_hooks_tick header updated, BroadcastChannel ref/unref return test added) and I found nothing new. Deferring to a maintainer because the dispatchOnlineEvent/dispatchOnline split changes the Worker state-machine timing across threads, and the process_origin() OnceLock makes origin_timer process-global — both are the kind of lifecycle change worth a human sign-off, and build #74680 is still running.

What was reviewed:

• dispatchOnlineEvent split: confirmed it only posts the open event; the Pending→Running flip and fireEarlyMessages stay where they were, so message routing/queueing is unchanged.
• Error-clone retry in dispatchErrorWithValue: gated on !serialized && !scope.exception() + dynamicDowncast<ErrorInstance>, uses putDirect + setStackPropertyAlreadyMaterialized() so the retry can't re-enter prepareStackTrace; code read below still runs.
• process_origin(): OnceLock<(Instant, u64)> is thread-safe; first VM (main thread) initialises it before any worker VM is created.
• #emitAsyncHooksInit: snapshot-before-iterate matches node's tmp_array; throwing hook → process.exit(1) matches the existing TickObject site.

Extended reasoning...

Overview

Six Node-compat behaviour fixes across the worker stack plus eight vendored upstream tests and two Bun-side tests. Source changes: src/js/node/worker_threads.ts (diagnostics_channel publish, async_hooks WORKER init, #hasRef bookkeeping), src/js/node/async_hooks.ts (init hook this binding), src/js/internal/async_hooks_tick.ts (comment), src/jsc/VirtualMachine.rs (process-global origin_timer/origin_timestamp via OnceLock), src/jsc/bindings/webcore/Worker.{cpp,h} (split dispatchOnlineEvent from dispatchOnline, error-clone retry on throwing prepareStackTrace), src/jsc/web_worker.rs (call WebWorker__dispatchOnlineEvent before entry-point load), src/jsc/bindings/webcore/JSBroadcastChannel.cpp (ref() returns this).

Security risks

None identified. No auth/crypto/permissions surface. The error-clone retry mutates a worker-thread ErrorInstance whose thread is terminating; the diagnostics_channel is resolved at module load so it isn't built from tampered primordials (which the PR calls out and which the existing tampered-Map test would have caught).

Level of scrutiny

High. The dispatchOnlineEvent split touches the Worker state machine documented in Worker.h — the PR description records two rejected attempts that regressed the suite, and the final shape moves only the event post while leaving the Pending→Running flip and fireEarlyMessages in place. That reasoning checks out against the code (postTaskToWorkerGlobalScope queues on Pending, so a parent's online→getHeapSnapshot() still works), but it is a deliberate change to cross-thread lifecycle timing and a removed comment previously defended the opposite ordering. The process_origin() change makes per-VM state process-global, which is correct per Node/WHATWG but changes the meaning of origin_timer for every worker VM.

Other factors

All five of my previous inline findings were addressed in d7e1659 and the threads are resolved. The reviewer who set the bar for this PR ("we should not add any tests that dont pass here") has adopted it and resolved the merge; build #74680 on the latest commit is still in progress, so CI status on the final shape (particularly the online-timing change across all shards) isn't confirmed yet. Given the scope — C++/Rust worker lifecycle across threads — and the active maintainer engagement, this should get a human approval rather than a bot one.

[robobun]

Merged main (23 commits) in 3b0831e. Three files conflicted, all against #40592 (--no-ffi-cc), which lands on the worker execArgv parsing this branch reshaped. Summarizing since it is a semantic merge, not a textual one:

• Main added --no-ffi-cc to its small WorkerExecArgvFlags { allow_addons, allow_ffi_cc } and a parse_worker_exec_argv_flags hook. This branch already replaced that hook with parse_worker_exec_argv, which returns WorkerExecArgv (addons, the per-thread CA flag, the cpu-prof options) and scans the whole execArgv. The resolution keeps this branch's struct and hook and folds main's flag into them: WorkerExecArgv.allow_ffi_cc: Option<bool>, set like allow_addons (Some(!seen) when the worker has its own execArgv), and web_worker.rs ANDs both with the parent's values, so a Worker cannot re-enable what its parent disabled. Main's struct and hook are gone; VirtualMachine::allow_ffi_cc() and the rest of Add --no-ffi-cc and make --no-addons disable bun:ffi cc() #40592 are unchanged.
• cc.test.ts's new "disabling cc()" block passes here, including the three Worker cases (--no-ffi-cc inherited into a Worker with an empty execArgv, a Worker disabling cc() for itself through execArgv, a Worker not re-enabling it).

Also checked on the merged debug build: no-addons.test.ts, worker_threads.test.ts, perf_hooks, test-use-system-ca, cpu-prof.test.ts, worker.test.ts and broadcast-channel.test.ts (the one failure is the #37075 flood timing test), 53 vendored node files, rust:clippy and cargo fmt --check.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

[robobun]

Merged main (301 commits) in 94cb78e. Seven files conflicted; two of the conflicts are semantic, so summarizing for Ciro:

#41383 put this branch's online-before-entry change on main (it cites this PR). The resolution takes main's shape: workerThreadStarted() posts open while the state stays Pending, so the branch's extra State::Started, the wider isOnline() and the extra switch arm are gone, and the WorkerMessagingProxy / web_worker.rs delta against main is now only hasRef, ELU and the error.code carrier. The branch's two 'open' event order tests in worker.test.ts duplicated main's new open event block and are dropped; the one case main lacks (open fires for an entry that never returns) is folded into that block. online fires before the entry point finishes in worker_threads.test.ts stays, it blocks the entry on an Atomics wait and is distinct from main's three.

#40862 / #40825 rebuilt the root store (lazy DER sets, the Linux system loader in Rust) and decided that the default store trusts OpenSSL's default paths ($SSL_CERT_FILE, the hash directory) in every mode, pinned by tests that also pass on 1.4.1. That supersedes the efc5781 decision in this thread (flagless rejects SSL_CERT_FILE); please push back if you want that back, but it would now mean reverting main's pinned behaviour. The resolution keeps main's builder and changes two things in it: the system store joins per the decision of the thread the store is built for (the use_system_ca parameter, us_resolve_use_system_ca) instead of the process flag, and --use-openssl-ca still selects the default lookups instead of bundled plus system, as node's NewRootCertStore does. The two-slot shared store, us_is_shared_default_ca_store, the SSL_CTX ex_data stamp and the per-thread default client context are unchanged. get_peer_certificate's fallback takes main's us_ssl_ctx_has_user_ca test with the per-thread store. Since SSL_CERT_FILE is now in every default store, the hermetic Linux tests cannot use it as a system-only root any more: they now put the CA under a non-hash file name in SSL_CERT_DIR, which the Linux system loader reads and the default store's hashed-directory lookup does not. The --use-openssl-ca row of the connection matrix flips to rejected for the same reason. The description's store bullet is updated.

The seventh file, uws/lib.rs, only needed the us_ssl_ctx_use_system_ca extern to name crate::SslCtx after main dropped SSL_CTX from the local import list.

Checked on the merged debug build: test-use-system-ca (26 tests, main's new default-path and system-loader blocks included), worker_threads.test.ts, perf_hooks, worker.test.ts, fetch.tls, node-tls-cert (285 pass), 65 vendored node files (the CA and worker sets), rust:clippy, cargo fmt --check, prettier and clang-format.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

[robobun]

A note for the merge order with #43089.

#43089 makes node:quic take the default CA store when no ca is given. TlsContext::new (src/runtime/node/quic/tls.rs) calls two new wrappers in src/uws/lib.rs, shared_default_ca_store() and default_ca_store(). Their declarations sit next to the us_get_shared_default_ca_store declaration that this PR changes.

This PR gives both getters a use_system_ca argument. So the two PRs conflict at those lines, and that is on purpose: a separate zero-argument declaration of us_get_default_ca_store would still build and link against the new definition.

The PR that merges second has to pass the decision of the thread from node:quic. If this PR merges first, I will do that on #43089.

[robobun]

#45209 registers the on() and once() listeners of a MessagePort in the native listener list and deletes the wrapper functions in injectFakeEmitter. this in such a listener is the port there. If #45209 merges first, the two .$call hunks of this PR in wrapped() and onceWrapper() (src/js/node/worker_threads.ts) are not necessary, and they conflict with it.

[robobun]

A note for the merge order: #45802 makes process.hrtime() read uv_hrtime(), as Node does. The test hrtime, uptime, Bun.nanoseconds and performance share the parent's origin in this PR brackets process.uptime(), Bun.nanoseconds() and performance.now() between two process.hrtime.bigint() readings. That holds only while hrtime counts from process start, and Node fails the same test. The two branches have no textual conflict there, so the PR that lands second must bracket each clock with readings of the same clock.