René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Windows CI: test/sandbox-blocked.test.js never ends under --test-force-exit","articleBody":"## What happened?\n\nSince #1029 put `--test-force-exit` on `npm test`, the `Tests (windows-latest)` job hangs in `npm test` until the 20-minute job limit cancels it. Both hangs looked at are the same file: **`test/sandbox-blocked.test.js`** never ends.\n\n- All eleven tests in the file pass, together in under a second. The file's process then stays alive: 1085 s and 1092 s until the cancel.\n- Every other unit file passes (4114 and 4123 of them). The 107 files listed under *Interrupted while running* are just the ones after `sandbox-blocked` in alphabetical order: they ran, but the reporter prints files in order and was waiting for this one.\n- Windows only. On macOS the same file with the same flags ended in under a second 30 times out of 30.\n- Not the environment: Node 24.21.0 and runner image `windows-2025-vs2026` / `20261002.596` in the green runs and in the hanging ones alike. Not `node_modules` either: nothing of it is tracked, `npm ci` takes its usual ~17 s, and the generated-file check reads only `src/preload` and `src/shared`.\n- Not tied to one branch: it hung on `claude/gitignore-node-modules-symlink` (run 38951875833, twice) and on `claude/mach-noch-1013-fcd6d3` (run 38953242527, #1031).\n\nWindows `npm test` over 2026-10-15/16: 37 runs before #1029 all green, then 3 green and 3 hanging.\n\n**Working hypothesis, not proven.** With `--test-force-exit` the root test in the child does not call `process.exit()` straight away: it waits for each reporter destination, that is its own stdout pipe, to emit `'unpipe'` and close first ([lib/internal/test_runner/test.js](https://github.com/nodejs/node/blob/v24.x/lib/internal/test_runner/test.js)). The parent waits for the child's `exit` *and* for `finished(child.stdout)`, with no per-file limit ([runner.js](https://github.com/nodejs/node/blob/v24.x/lib/internal/test_runner/runner.js)). If that `'unpipe'` never comes on a Windows pipe while something keeps the child's loop alive, the file never ends. Why this file and not the 76 others that use the same happy-dom helper is open.\n\n## Steps to reproduce\n\n1. Push any branch based on `main` after `d798320` (#1029).\n2. Watch `Tests (windows-latest)` → *Run npm test*. Not every run hangs (3 of the last 6 did).\n\n## Expected behaviour\n\n`npm test` on Windows ends in its usual ~2 minutes, and a file whose tests are through ends with them.\n\n## Mitigation in place\n\n`--test-force-exit` is taken off `npm test` (see the pull request that references this issue); `test:e2e` keeps it, because the hang #997 was about is an E2E one. This issue is about the cause, so the flag can come back to the unit suite — or stay off for a reason we know.\n\n## What to find out\n\n- [ ] A diagnostic run on Windows: `test/sandbox-blocked.test.js` alone, many times in a row, with and without `--test-force-exit` — does only the flag make it hang?\n- [ ] When it hangs: what keeps the child alive — a handle dump (`process.getActiveResourcesInfo()` from a timer in the file, or `why-is-node-running`), and whether the child has exited while its stdout stays open.\n- [ ] Whether `withDom()` not awaiting happy-dom's `window.close()` matters here (it returns a promise in happy-dom 20.14.5).\n- [ ] If it is Node's force-exit path: a minimal repro and a report upstream; if it is ours: the fix in the file or the helper.\n- [ ] Decide whether `npm test` gets `--test-force-exit` back, and update the table under *Time limits* in `docs/test-concept.md`.\n\n## App version\n\nNot app-related: test runner on CI, `main` from `d798320` on.\n\n## Operating system\n\nWindows (GitHub runner `windows-latest`, image `windows-2025-vs2026` `20261002.596`), Node 24.21.0.\n\n## Logs / screenshots\n\nFrom run 38953242527, job *Tests (windows-latest)*:\n\n```\n✖ test\\sandbox-blocked.test.js (1092833.9159ms)\n  'Promise resolution is still pending but the event loop has already resolved'\n##[error]The operation was canceled.\n```\n\nChecked on 2026-10-16. Related: #997, #1029.\n","author":{"url":"https://github.com/kkrafft1999","@type":"Person","name":"kkrafft1999"},"datePublished":"2026-10-16T19:43:38Z","url":"https://github.com/kkrafft1999/snotra/issues/1038"}