This is an automated email from the ASF dual-hosted git repository. github-merge-queue[bot] pushed a commit to branch gh-readonly-queue/main/pr-7976-2c2c0e5034e1e45fadfcdea5fa2affd122642db9 in repository https://gitbox.apache.org/repos/asf/texera.git
commit 0af18e0b013b64650bf34ffd5dcf3ae1cc2637d6 Author: Meng Wang <[email protected]> AuthorDate: Tue Aug 25 20:57:46 2026 +0000 ci(frontend): size the Vitest workers' heap, which the runner default under-provisions (#7976) ### What changes were proposed in this PR? `build / frontend (macos-latest)` has been dying on a V8 heap OOM inside a Vitest worker — the leg reports `200 passed (201)` with zero failed assertions, because the worker is killed mid-run rather than any test failing. The workers' heap size has never been configured. Vitest runs each spec file in a forked worker and rebuilds that worker's `execArgv` from scratch, keeping only `--cpu-prof` / `--heap-prof` / `--diagnostic-dir`; the `--max-old-space-size=8192` in `test:ci` predates the Karma → Vitest migration (#4862), sizes the parent process, and has never applied to a worker. Left unset, a worker takes V8's default, which tracks the machine's RAM — about 2 GB on `macos-arm64`, exactly the ceiling in the crash log, and why ubuntu and windows have never hit it. This sets `execArgv: ["--max-old-space-size=3072"]` in `frontend/vitest.config.ts` — Vitest's own option for sizing a worker ("Pass additional arguments to `node` process when spawning the worker") — so the limit reaches the workers, in CI and in local full-suite runs alike. 3 GB leaves ~4x headroom over the heaviest spec measured (712 MB) while keeping the leg's two concurrent forks inside the image's memory. `test:ci`'s own flag still sizes the parent, which holds the module graph, and is left alone. ### Any related issues, documentation, discussions? Closes #7975. Supersedes the timeout headroom added in #7713, which treated the same underlying pressure as runner variance: a worker near the heap ceiling stalls in stop-the-world GC (single mark-compact pauses of 7.4 s and 29.6 s appear in these logs), long enough to blow a `beforeEach`. Those timeouts are left in place. ### How was this PR tested? Measured the worker heap limit end-to-end in this project, on macOS with Vitest 4.1.10, using a probe spec that reports `v8.getHeapStatistics()`: | run | worker heap limit | |---|---| | before, through `test:ci` (parent flag only) | 4192 MB — the default; the worker's `execArgv` contains no `--max-old-space-size` | | after, through the same `nx test` path | 3168 MB | ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (claude-fable-5) --- frontend/vitest.config.ts | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/frontend/vitest.config.ts b/frontend/vitest.config.ts index 2fcb9dcbd0..5498e3043c 100644 --- a/frontend/vitest.config.ts +++ b/frontend/vitest.config.ts @@ -43,6 +43,16 @@ export default defineConfig({ // later on a 9–17 minute leg. testTimeout: 20000, hookTimeout: 30000, + // Each spec file runs in a forked worker, and Vitest rebuilds that worker's + // execArgv from scratch, keeping only the profiling flags -- so the + // --max-old-space-size in `test:ci`, which predates the Karma -> Vitest + // migration and sizes the parent process, has never applied to a worker. + // Left unset, a worker takes V8's default, which tracks the machine's RAM: + // about 2 GB on the macos-arm64 runners, which this suite now exhausts + // outright, killing the worker mid-run (#7975). 3 GB leaves ~4x headroom + // over the heaviest spec measured (712 MB) while keeping the leg's two + // concurrent forks inside the image's memory. + execArgv: ["--max-old-space-size=3072"], // Per-spec exclusions live in `angular.json` (the unit-test builder // applies them at the discovery stage, before Vitest's own filter, // which is what the Vitest team recommends — see the Vite warning
