aglinxinyuan opened a new pull request, #7623: URL: https://github.com/apache/texera/pull/7623
### What changes were proposed in this PR? The macOS leg of `build / frontend` goes red on a different unit test every few days — always a timeout, never the same spec, always green on rerun. Three occurrences in the last four days: | Run | Test | Error | | --- | --- | --- | | [31665399757](https://github.com/apache/texera/actions/runs/31665399757/job/94338769943) | `UserDatasetVersionCreatorComponent > onClickCreate creates a dataset with a sanitized name …` | `Test timed out in 5000ms` | | [31630884042](https://github.com/apache/texera/actions/runs/31630884042/job/94229059409) | `AdminUserComponent > sortByAffiliation compares affiliations …` | `Hook timed out in 10000ms` | | [31411656559](https://github.com/apache/texera/actions/runs/31411656559/job/93531487995) | `WorkflowRuntimeStatisticsComponent > should create` | `Test timed out in 5000ms` | **Root cause: the runner stalls, not the test.** The stall lands on whichever test happens to be executing. From run `31665399757` — one commit, one matrix, two OSes: | Measure | ubuntu-latest | macos-latest | | --- | --- | --- | | the spec file that failed (10 tests) | 240 ms | **11 727 ms** | | suite wall clock | 89.85 s | 252.88 s | | cumulative test time | 182.34 s | 307.69 s | | runner size | 4 cores / 16 GB | 3 cores / 7 GB | That file is not systematically slow — it took 219 ms on macOS in an earlier run, and 443 ms locally. The 11.7 s is a stall. jsdom + v8-coverage workers on 3 cores / 7 GB run under real memory pressure, which is where multi-second pauses come from. | Change | File | | --- | --- | | `testTimeout` 5s → 30s, `hookTimeout` 10s → 30s | `frontend/vitest.config.ts`, `frontend/vitest.browser.config.ts` | | `fail-fast: false` on the frontend matrix | `.github/workflows/build.yml` | | Timeouts row in the runner-setup table | `frontend/TESTING.md` | Bumping the one test's timeout would be whack-a-mole — the next stall picks a different spec. 30 s absorbs a stall an order of magnitude worse than any observed; a spec that legitimately needs 30 s is broken, and the job's own timeout still bounds a true hang. The `fail-fast` opt-out matches every other multi-leg matrix in `build.yml` (`platform`, `platform-integration`, `agent-service`, `infra`). Today one flaky OS cancels the other two legs, so the run no longer says whether the failure reproduces off that OS — exactly the evidence needed to tell a runner flake from a real break. ``` Before: macOS stalls 5s -> that test fails -> ubuntu + windows cancelled After: macOS stalls 5s -> absorbed; a real break still fails all legs ``` If macOS keeps flaking after this, the next lever is capping `maxWorkers` on that leg to cut memory pressure. Left out here: it trades wall clock for stability and can't be measured from a non-macOS box. ### Any related issues, documentation, discussions? Related to #6073 — the same failure mode on the Windows leg, which already proposes both of these remedies. Left open and assigned; the three new macOS occurrences are recorded there. ### How was this PR tested? No production code is touched; the change is to the test harness and CI config. | Check | Result | | --- | --- | | `yarn test:ci` (full jsdom suite, new config) | 200 files, 4433 passed / 1 skipped — same counts as CI's ubuntu leg | | config actually wired | a throwaway spec with a 6 s `beforeEach` + 8 s body passes (14 026 ms); the 8 s body fails on the old 5 s default. Removed before commit | | `build.yml` parses | `js-yaml` load → `jobs.frontend.strategy['fail-fast'] === false` | | formatting | `prettier-eslint --list-different` clean | The flake itself can't be reproduced on demand — that's the nature of a runner stall. What this PR asserts is verifiable: the ceiling that the stalls blow past is now 6× higher, and the surviving matrix legs still report their own results. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 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]
