Repository navigation
chore(ci): drop Windows-specific Node pin, track 24 on all platforms - #2824
Conversation
Windows CI was pinned to Node 24.15.0 to avoid a libuv file-watcher assertion crash (libuv/libuv#5010). That fix shipped upstream in libuv#5152, cherry-picked into Node via nodejs/node#65118, and first released in Node 24.21.0 (2026-09-08). The pin's original reason no longer applies, so Windows can track the same floating `24` version as every other platform. This also moves Windows off 24.15.0, a version that predates some V8 Maglev JIT crash fixes reported upstream in nodejs/node#62260, which may reduce (though not eliminate, per upstream measurements) the STATUS_STACK_BUFFER_OVERRUN crashes seen in cedarjs#2146.
👷 Deploy request for cedarjs pending review.Visit the deploys page to approve it
|
|
| Command | Status | Duration | Result |
|---|---|---|---|
nx run-many -t build:pack --exclude create-ceda... |
✅ Succeeded | 3s | View ↗ |
nx run-many -t build |
✅ Succeeded | <1s | View ↗ |
nx run-many -t build --output-style=stream |
✅ Succeeded | 3s | View ↗ |
💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗
☁️ Nx Cloud last updated this comment at 2026-09-23 12:46:14 UTC
|
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review. 📝 SummarySummary by CodeRabbit
WalkthroughThe setup step now uses Node 24 on all runners instead of pinning Windows to Node 24.15.0. Its comments now state that the cited libuv file-watcher fix shipped in Node 24.21.0. ChangesNode.js Setup
Priority: ⚪ Not assessed Merge Risk: ⚪ Minimal · up to Windows now follows the same Node 24 selection as other runners; no material merge-blocking issue is established. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…ed build (#2830) ## Follow-up to #2824 While babysitting #2823's rerun (to validate #2824's fix for the Maglev crash pattern in #2146), a **new** Windows failure surfaced on the `build-lint-test` job, in `@cedarjs/api-server-watch:test`: ``` Assertion failed: !_wcsnicmp(filename, dir, dirlen), file src\win\fs-event.c, line 72 ``` This is the exact libuv file-watcher assertion (libuv/libuv#5010) that #2824 was supposed to route around by dropping Cedar's stale `24.15.0` Windows pin in favor of a floating `24`, since the real fix shipped upstream in Node 24.21.0. Turns out that's not sufficient on its own. The job's "Set up Node.js" step logs: ``` Found in cache @ C:\hostedtoolcache\windows\node\24.20.0\x64 node: v24.20.0 ``` GitHub's Windows runner image currently pre-caches Node **24.20.0** — one release behind 24.21.0. `actions/setup-node` defaults to `check-latest: false`, so for a floating `'24'` version spec it happily uses that stale cached build instead of checking whether a newer 24.x release exists. The libuv fix never gets picked up as a result. This PR adds `check-latest: true` to the Node setup step so `actions/setup-node` always checks for (and downloads, if needed) the latest matching release instead of trusting a possibly-stale runner cache. ### Test plan - [ ] Confirm a subsequent Windows CI run resolves Node to >= 24.21.0 (watch for `node: v24.2x.x` in the "Set up Node.js" step logs, not `24.20.0`) - [ ] Confirm `@cedarjs/api-server-watch:test` and other Windows file-watcher-dependent tests pass without the `fs-event.c` assertion
…2824) ## Why Windows CI has been pinned to Node `24.15.0` since the libuv file-watcher assertion crash (libuv/libuv#5010) was discovered. That reason no longer applies: the fix shipped in libuv#5152, was cherry-picked into Node via nodejs/node#65118, and first released in **Node 24.21.0** (2026-09-08). Investigating #2146 (recurring nightly Windows CI failures), the dominant signature is a V8 Maglev JIT crash (exit code `3221226505` / `STATUS_STACK_BUFFER_OVERRUN`, tracked upstream at nodejs/node#62260). We already mitigate this for `cedar dev`'s web server via `--no-maglev` (`packages/cli/src/commands/dev/devHandler.ts`), but: - the crash still recurs even with `--no-maglev` present — confirmed upstream on 2026-09-21 that the flag only reduces the crash rate ~5x, it doesn't eliminate it - it also crashes in paths the flag never covers, e.g. `yarn install` itself (observed in a Sept 10 RSC smoke-tests run) One upstream reporter also noted their repro doesn't reproduce on Node `24.19.0`/`22.23.2` while it does on `24.12.0`, suggesting additional relevant fixes landed in that range too — all after our `24.15.0` pin. ## What Drop the Windows-only version override in `set-up-job/action.yml` so Windows tracks the same floating `24` as every other platform, picking up both the libuv fix and any V8/Maglev-adjacent fixes in later 24.x releases. This isn't expected to fully eliminate the Maglev crashes (upstream is explicit that `--no-maglev` alone doesn't), but it removes an unnecessary constraint and may reduce the frequency. Worth keeping `--no-maglev` and extending it to the still-uncovered paths (`yarn install`/corepack, `cedar serve`, api-server-watch, `cedar storybook`) as a separate follow-up if failures persist after this lands. ## Test plan - [ ] Nightly Windows run (`.github/workflows/nightly-windows.yml`) picks up Node 24.21.0+ and completes without regressions - [ ] Watch #2146 for a change in failure frequency/signature over the following nights (cherry picked from commit 6923b19)
…ed build (#2830) ## Follow-up to #2824 While babysitting #2823's rerun (to validate #2824's fix for the Maglev crash pattern in #2146), a **new** Windows failure surfaced on the `build-lint-test` job, in `@cedarjs/api-server-watch:test`: ``` Assertion failed: !_wcsnicmp(filename, dir, dirlen), file src\win\fs-event.c, line 72 ``` This is the exact libuv file-watcher assertion (libuv/libuv#5010) that #2824 was supposed to route around by dropping Cedar's stale `24.15.0` Windows pin in favor of a floating `24`, since the real fix shipped upstream in Node 24.21.0. Turns out that's not sufficient on its own. The job's "Set up Node.js" step logs: ``` Found in cache @ C:\hostedtoolcache\windows\node\24.20.0\x64 node: v24.20.0 ``` GitHub's Windows runner image currently pre-caches Node **24.20.0** — one release behind 24.21.0. `actions/setup-node` defaults to `check-latest: false`, so for a floating `'24'` version spec it happily uses that stale cached build instead of checking whether a newer 24.x release exists. The libuv fix never gets picked up as a result. This PR adds `check-latest: true` to the Node setup step so `actions/setup-node` always checks for (and downloads, if needed) the latest matching release instead of trusting a possibly-stale runner cache. ### Test plan - [ ] Confirm a subsequent Windows CI run resolves Node to >= 24.21.0 (watch for `node: v24.2x.x` in the "Set up Node.js" step logs, not `24.20.0`) - [ ] Confirm `@cedarjs/api-server-watch:test` and other Windows file-watcher-dependent tests pass without the `fs-event.c` assertion (cherry picked from commit 7f720ba)

Why
Windows CI has been pinned to Node
24.15.0since the libuv file-watcherassertion crash (libuv/libuv#5010) was discovered. That reason no longer
applies: the fix shipped in libuv#5152, was cherry-picked into Node via
nodejs/node#65118, and first released in Node 24.21.0 (2026-09-08).
Investigating #2146 (recurring nightly Windows CI failures), the
dominant signature is a V8 Maglev JIT crash (exit code
3221226505/STATUS_STACK_BUFFER_OVERRUN, tracked upstream at nodejs/node#62260). Wealready mitigate this for
cedar dev's web server via--no-maglev(
packages/cli/src/commands/dev/devHandler.ts), but:--no-maglevpresent — confirmedupstream on 2026-09-21 that the flag only reduces the crash rate ~5x, it
doesn't eliminate it
yarn installitself (observed in a Sept 10 RSC smoke-tests run)
One upstream reporter also noted their repro doesn't reproduce on Node
24.19.0/22.23.2while it does on24.12.0, suggesting additionalrelevant fixes landed in that range too — all after our
24.15.0pin.What
Drop the Windows-only version override in
set-up-job/action.ymlsoWindows tracks the same floating
24as every other platform, picking upboth the libuv fix and any V8/Maglev-adjacent fixes in later 24.x
releases.
This isn't expected to fully eliminate the Maglev crashes (upstream is
explicit that
--no-maglevalone doesn't), but it removes an unnecessaryconstraint and may reduce the frequency. Worth keeping
--no-maglevandextending it to the still-uncovered paths (
yarn install/corepack,cedar serve, api-server-watch,cedar storybook) as a separatefollow-up if failures persist after this lands.
Test plan
.github/workflows/nightly-windows.yml) picksup Node 24.21.0+ and completes without regressions
over the following nights