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-7717-8bcc8ebc92ec4abb8f1d74e7baeff9dd71242b74 in repository https://gitbox.apache.org/repos/asf/texera.git
commit e80add40cc5564af7dd9d989b1dd2b0943633422 Author: Meng Wang <[email protected]> AuthorDate: Mon Aug 17 08:03:20 2026 +0000 fix(frontend): give unit tests timeout headroom for loaded macOS runners (#7717) ### What changes were proposed in this PR? The `build / frontend (macos-latest)` leg failed 6 times between 08-14 and 08-17, each time on a **pure timeout in a different spec** — never a failed assertion (details and per-failure table in #7713). The leg's own wall time swings ~2x run to run (9m17s–16m52s), and the same test that runs in ~400ms on ubuntu has been observed at 11s+ inside a `beforeEach` on a loaded macOS runner — while Vitest's default limits (5s test / 10s hook) are fixed absolute values that don't scale with runner load. Nothing in the frontend test setup changed in that window; the margin is simply thin enough that ordinary macOS runner variance crosses it. - Set `testTimeout: 20000` and `hookTimeout: 30000` in `frontend/vitest.config.ts` (which previously set neither, inheriting the 5s/10s defaults) — roughly 4x/3x the worst observed times. Both are needed: 4 of the 6 failures hit the test timeout, 2 hit the hook timeout. - The cost is that a genuinely hung test reports 15–20s later, negligible against a 9–17 minute leg and strictly cheaper than re-running CI and eroding the signal a red leg carries. - `vitest.browser.config.ts` (the browser-mode leg) deliberately keeps the defaults — no timeout failures have been observed there. - Deliberately **not** making the individual specs cheaper: some are expensive on purpose (`hub-search-result` / `search` stand up real child components to work around the coverage-attribution loss in #7458; undoing that would revert #7627 / #7535). ### Any related issues, documentation, discussions? Closes #7713. ### How was this PR tested? - Config-only change with no executable code; the frontend CI legs themselves exercise it by loading `vitest.config.ts` for the full 202-spec / 4704-test suite. - Type-checked the edited config against Vitest's `InlineConfig` typings (`tsc --noEmit` passes — the option names and types are validated), and `prettier --check` passes, so `format:ci` is unaffected. - No spec sets a per-test timeout override (verified by grep), so the global raise applies uniformly. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (claude-opus-4-8) --------- Signed-off-by: Meng Wang <[email protected]> Co-authored-by: Copilot Autofix powered by AI <[email protected]> --- frontend/vitest.config.ts | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/frontend/vitest.config.ts b/frontend/vitest.config.ts index 9cb2f82f88..2fcb9dcbd0 100644 --- a/frontend/vitest.config.ts +++ b/frontend/vitest.config.ts @@ -34,6 +34,15 @@ export default defineConfig({ // which Angular's `fakeAsync` requires. Karma+Jasmine installed this // implicitly; the @angular/build:unit-test path doesn't. setupFiles: ["src/test-zone-setup.ts"], + // Headroom over Vitest's defaults (5s test / 10s hook) for the shared + // macos-latest runners, whose wall time swings ~2x run to run: the same + // test that takes ~400ms on ubuntu has been observed at 11s+ in a + // beforeEach on a loaded macOS runner, and the leg was failing on pure + // timeouts in a different spec nearly every time (#7713). These limits are + // 4x/3x the defaults; a genuinely hung test still fails, 15–20 seconds + // later on a 9–17 minute leg. + testTimeout: 20000, + hookTimeout: 30000, // 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
