mengw15 opened a new pull request, #7976: URL: https://github.com/apache/texera/pull/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. `frontend/package.json` asks for 8 GB in `test:ci`, but that flag applies to the parent process only: Vitest rebuilds its fork workers' `execArgv` from scratch, keeping only `--cpu-prof` / `--heap-prof` / `--diagnostic-dir`, so `--max-old-space-size` is dropped and every worker runs at V8's default. That default tracks the image's RAM — about 2 GB on `macos-arm64`, which is exactly the ceiling in the crash log, and why ubuntu and windows have never hit it. - Set `NODE_OPTIONS: --max-old-space-size=3072` on the `frontend` job. `NODE_OPTIONS` is an environment variable, so it *is* inherited by the workers. The macOS leg runs 2 concurrent forks, so 3 GB each stays within the image's RAM while giving ~4x headroom over the highest per-spec peak measured (712 MB). Per-command flags still take precedence where they are set, so `build:ci` keeps its own 8 GB. - Add `fail-fast: false` to the `frontend` matrix, matching the four other matrices in this workflow. Without it, the dying macOS leg cancels the others — on #7917 the windows leg was reported red purely for this reason, after its own run finished `201 passed`. Note this also makes the ceiling explicit and uniform across the matrix: ubuntu and windows move from an implicit ~4 GB default to the same 3 GB, still well clear of the observed peaks. ### 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 (`ng test --watch=false` on a probe spec reporting `v8.getHeapStatistics()`), on macOS with Vitest 4.1.10: | run | worker heap limit | |---|---| | today's `test:ci` (parent flag only) | 4192 MB — the default; the worker's `execArgv` contains no `--max-old-space-size` | | with `NODE_OPTIONS=--max-old-space-size=3072` | 3168 MB | Also confirmed a command-line flag still wins over `NODE_OPTIONS` (`NODE_OPTIONS=3072` + CLI `8192` → 8288 MB), so the prod build's own limit is unaffected, and validated the edited workflow with a YAML parser. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (claude-fable-5) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
