You are viewing a plain text version of this content. The canonical link for it is here.

Posted to notifications@texera.apache.org by "aglinxinyuan (via GitHub)" <gi...@apache.org> on 2026/08/13 05:03:29 UTC

[PR] fix(test, frontend): raise Vitest timeouts for CI stalls [texera]

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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] fix(test, frontend): raise Vitest timeouts for CI stalls [texera]

Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.

github-actions[bot] commented on PR #7623:
URL: https://github.com/apache/texera/pull/7623#issuecomment-5276218890

   <!-- texera-benchmarks-comment -->
   ## ⚠️ Benchmark changes need a look
   
   🟢 0 better · 🔴 4 worse · ⚪ 11 noise (<±5%) · 0 without baseline
   
   > Compared against main `310ab88` benchmarked on **this same runner**, so the delta is largely free of cross-runner hardware noise. The "7d avg" column still reflects the gh-pages dashboard. Treat <±5% as noise unless repeated.
   
   [Dashboard](https://apache.github.io/texera/dev/bench/) · [Run](https://github.com/apache/texera/actions/runs/31669016917)
   
   | | config | throughput | MB/s | latency | max Δ latest / 7d |
   |---|---|---:|---:|---:|---:|
   | 🔴 | bs=10 sw=10 sl=64 | 434 | 0.265 | 21,648/32,127/32,127 us | 🔴 -5.0% / 🔴 +97.0% |
   | 🔴 | bs=100 sw=10 sl=64 | 939 | 0.573 | 104,692/159,560/159,560 us | 🔴 +17.3% / 🔴 +47.5% |
   | ⚪ | bs=1000 sw=10 sl=64 | 1,084 | 0.662 | 925,470/1,003,573/1,003,573 us | ⚪ within ±5% / 🟢 -7.1% |
   
   <details><summary>Baseline details</summary>
   
   Latest main `310ab88` from same runner
   
   | config | metric | PR | latest main | 7d avg | Δ latest | Δ 7d |
   |---|---|---:|---:|---:|---:|---:|
   | bs=10 sw=10 sl=64 | throughput | 434 tuples/sec | 457 tuples/sec | 775.33 tuples/sec | -5.0% | -44.0% |
   | bs=10 sw=10 sl=64 | MB/s | 0.265 MB/s | 0.279 MB/s | 0.473 MB/s | -5.0% | -44.0% |
   | bs=10 sw=10 sl=64 | p50 | 21,648 us | 22,627 us | 12,743 us | -4.3% | +69.9% |
   | bs=10 sw=10 sl=64 | p95 | 32,127 us | 31,747 us | 16,310 us | +1.2% | +97.0% |
   | bs=10 sw=10 sl=64 | p99 | 32,127 us | 31,747 us | 18,926 us | +1.2% | +69.7% |
   | bs=100 sw=10 sl=64 | throughput | 939 tuples/sec | 973 tuples/sec | 1,001 tuples/sec | -3.5% | -6.2% |
   | bs=100 sw=10 sl=64 | MB/s | 0.573 MB/s | 0.594 MB/s | 0.611 MB/s | -3.5% | -6.2% |
   | bs=100 sw=10 sl=64 | p50 | 104,692 us | 101,825 us | 101,399 us | +2.8% | +3.2% |
   | bs=100 sw=10 sl=64 | p95 | 159,560 us | 136,023 us | 108,206 us | +17.3% | +47.5% |
   | bs=100 sw=10 sl=64 | p99 | 159,560 us | 136,023 us | 118,195 us | +17.3% | +35.0% |
   | bs=1000 sw=10 sl=64 | throughput | 1,084 tuples/sec | 1,110 tuples/sec | 1,026 tuples/sec | -2.3% | +5.6% |
   | bs=1000 sw=10 sl=64 | MB/s | 0.662 MB/s | 0.677 MB/s | 0.626 MB/s | -2.2% | +5.7% |
   | bs=1000 sw=10 sl=64 | p50 | 925,470 us | 901,558 us | 996,304 us | +2.7% | -7.1% |
   | bs=1000 sw=10 sl=64 | p95 | 1,003,573 us | 995,220 us | 1,042,531 us | +0.8% | -3.7% |
   | bs=1000 sw=10 sl=64 | p99 | 1,003,573 us | 995,220 us | 1,074,934 us | +0.8% | -6.6% |
   
   </details>
   
   <details><summary>Raw CSV</summary>
   
   ```csv
   config_idx,batch_size,schema_width,string_len,num_batches,total_ms,total_tuples,total_bytes,tuples_per_sec,mb_per_sec,lat_p50_us,lat_p95_us,lat_p99_us
   0,10,10,64,20,461.15,200,128000,434,0.265,21647.74,32127.13,32127.13
   1,100,10,64,20,2131.01,2000,1280000,939,0.573,104691.64,159559.51,159559.51
   2,1000,10,64,20,18447.26,20000,12800000,1084,0.662,925470.16,1003572.54,1003572.54
   ```
   
   </details>
   


-- 
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] fix(test, frontend): raise Vitest timeouts for CI stalls [texera]

Posted by "aglinxinyuan (via GitHub)" <gi...@apache.org>.

aglinxinyuan commented on PR #7623:
URL: https://github.com/apache/texera/pull/7623#issuecomment-5300975642

All four addressed in fb5ec5a, plus a description edit.

- **`Closes #6073`** — promoted from "Related to". The two follow-ups it lists are exactly what this ships. It's assigned to @rbelavadi for the Windows-side tracking, so say the word if you'd rather it stay open and I'll revert to a plain reference.
- **Browser `hookTimeout`** — dropped. Confirmed in the pinned 4.1.10 that `browser.enabled` already resolves 15s/30s, so that line set the value it inherited; the remaining `testTimeout` is now documented as a 15s → 30s bump rather than 6x.
- **`timeout-minutes: 30`** on the frontend job, so the "the job's own timeout bounds a true hang" sentence is backed by a real key rather than GitHub's implicit 6h cap. Green legs run 4-12 min and the install step alone is allowed 20.
- **fail-fast rationale** — now names `platform`, `platform-integration`, `agent-service` and `infra` instead of claiming every multi-leg matrix. `amber-integration` (2 OS legs) and `pyamber` (3 Python versions) are the counterexamples; left alone here, happy to open the follow-up.

Description updated to match: per-config timeout rows, the new job cap, and the ceiling split (6x under jsdom, 2x in browser mode).

--
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] fix(test, frontend): raise Vitest timeouts for CI stalls [texera]

Posted by "Yicong-Huang (via GitHub)" <gi...@apache.org>.

Yicong-Huang commented on PR #7623:
URL: https://github.com/apache/texera/pull/7623#issuecomment-5314062625

   This PR conflicts with the base branch; please resolve the conflicts before review can continue.


-- 
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] fix(ci, test, frontend): stop the frontend matrix manufacturing false reds [texera]

Posted by "Yicong-Huang (via GitHub)" <gi...@apache.org>.

Yicong-Huang commented on code in PR #7623:
URL: https://github.com/apache/texera/pull/7623#discussion_r3840871924


##########
.github/workflows/build.yml:
##########
@@ -86,7 +86,24 @@ jobs:
   frontend:
     if: ${{ inputs.run_frontend }}
     runs-on: ${{ matrix.os }}
+    # Only the "Install dependency" step below is bounded, so a spec that
+    # truly hangs would otherwise run to GitHub's implicit 6h cap — billed at

Review Comment:
   `macos-latest` is a standard runner, and this repository is public. [GitHub's runner policy](https://docs.github.com/en/actions/reference/runners/github-hosted-runners#standard-github-hosted-runners-for-public-repositories) therefore makes this usage free and unlimited, not billed at a 10x multiplier. Please remove the billing claim here and in the matching PR-description row; the six-hour resource/concurrency bound still justifies the cap.



##########
frontend/TESTING.md:
##########
@@ -47,6 +47,7 @@ For repo-wide testing philosophy (TDD, characterization tests, "every test must
 | Coverage                 | `@vitest/coverage-v8`                                                                                                                  |
 | Test setup               | `src/test-zone-setup.ts` wraps `it`/`test` in an Angular ProxyZone (Vitest does not provide one and Angular's `fakeAsync` requires it) |
 | Globals                  | `globals: true` in `vitest.config.ts`, so `describe / it / expect / vi / beforeEach` come from the runtime — no per-file imports       |
+| Timeouts                 | Raised over Vitest's defaults because macOS CI runners stall for seconds at a time (#6073, #7713). jsdom: 20s per test / 30s per hook (`vitest.config.ts`, defaults 5s/10s). Browser mode: 30s per test (`vitest.browser.config.ts`), hooks left at the 30s `browser.enabled` already resolves — its per-test default is 15s |

Review Comment:
   `the 30s` needs a noun for the following `browser.enabled` clause to modify.
   ```suggestion
   | Timeouts                 | Raised over Vitest's defaults because macOS CI runners stall for seconds at a time (#6073, #7713). jsdom: 20s per test / 30s per hook (`vitest.config.ts`, defaults 5s/10s). Browser mode: 30s per test (`vitest.browser.config.ts`), hooks left at the 30s default that `browser.enabled` already resolves — its per-test default is 15s |
   ```



-- 
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] fix(test, frontend): raise Vitest timeouts for CI stalls [texera]

Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.

github-actions[bot] commented on PR #7623:
URL: https://github.com/apache/texera/pull/7623#issuecomment-5276184016

   <!-- texera-reviewer-suggestion -->
   ### Automated Reviewer Suggestions
   
   Based on the `git blame` history of the changed files, we recommend the following reviewers:
   
   - **Committers with relevant context:** `@parshimers`
     You can request their reviews formally with `/request-review @parshimers`.
   
   - **Contributors with relevant context:** `@renovate-bot`, `@Yicong-Huang`
     You can notify them by mentioning `@renovate-bot`, `@Yicong-Huang` in a comment.
   


-- 
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] fix(test, frontend): raise Vitest timeouts for CI stalls [texera]

Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.

github-actions[bot] commented on PR #7623:
URL: https://github.com/apache/texera/pull/7623#issuecomment-5276183505

   <!-- backport-auto-label-report -->
   ### Backport auto-label report
   
   This `fix:` PR was checked against each actively-supported release branch. `release/*` labels drive the post-merge backport, so add or remove one to change where this fix lands.
   
   | Release branch | Analysis |
   | --- | --- |
   | ✅ `release/v1.2` | Change detected on this branch — label added; this fix is queued to backport here. Requested review from @xuang7. |
   
   _[Auto-label run](https://github.com/apache/texera/actions/runs/31669007812)._


-- 
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] fix(test, frontend): raise Vitest timeouts for CI stalls [texera]

Posted by "Yicong-Huang (via GitHub)" <gi...@apache.org>.

Yicong-Huang commented on code in PR #7623:
URL: https://github.com/apache/texera/pull/7623#discussion_r3789082040


##########
.github/workflows/build.yml:
##########
@@ -86,7 +86,20 @@ jobs:
   frontend:
     if: ${{ inputs.run_frontend }}
     runs-on: ${{ matrix.os }}
+    # Only the "Install dependency" step below is bounded, so a spec that
+    # truly hangs would otherwise run to GitHub's implicit 6h cap — billed at
+    # 10x on the macOS leg. Recent green runs take 4-12 minutes and install
+    # alone may take 20, so 30 bounds a hang while still absorbing a cold
+    # yarn cache on a slow runner.

Review Comment:
   The 20 here is the `Install dependency` step's own budget (`:142`), not an observed duration — install measured 37-74s across this PR's three legs.
   
   The conclusion then doesn't follow: if install did approach 20, the remaining steps still need 8-9.5 minutes (measured), putting the job at 28-29.5 against the 30 cap. No absorption is left in exactly the cold-cache-on-a-slow-runner case the sentence names.
   
   The value is fine at 2.8x the worst leg; sizing it from observed runs like `amber-integration` (`:375-376`) makes the sentence carry it.
   
   ```suggestion
       # 10x on the macOS leg. Recent green legs run 8-11 minutes end to end, so
       # 30 leaves roughly 3x headroom for a cold yarn cache on a slow runner
       # without masking a hang.
   ```



-- 
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] fix(ci, test, frontend): stop the frontend matrix manufacturing false reds [texera]

Posted by "aglinxinyuan (via GitHub)" <gi...@apache.org>.

aglinxinyuan merged PR #7623:
URL: https://github.com/apache/texera/pull/7623


-- 
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] fix(ci, test, frontend): stop the frontend matrix manufacturing false reds [texera]

Posted by "aglinxinyuan (via GitHub)" <gi...@apache.org>.

aglinxinyuan commented on PR #7623:
URL: https://github.com/apache/texera/pull/7623#issuecomment-5417231389

   @Yicong-Huang, can you review the PR?


-- 
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] fix(ci, test, frontend): stop the frontend matrix manufacturing false reds [texera]

Posted by "aglinxinyuan (via GitHub)" <gi...@apache.org>.

aglinxinyuan commented on code in PR #7623:
URL: https://github.com/apache/texera/pull/7623#discussion_r3840945052


##########
.github/workflows/build.yml:
##########
@@ -86,7 +86,24 @@ jobs:
   frontend:
     if: ${{ inputs.run_frontend }}
     runs-on: ${{ matrix.os }}
+    # Only the "Install dependency" step below is bounded, so a spec that
+    # truly hangs would otherwise run to GitHub's implicit 6h cap — billed at

Review Comment:
   You're right, and I read the policy rather than take it from the thread: GitHub's [runner docs](https://docs.github.com/en/actions/reference/runners/github-hosted-runners) say use of the standard GitHub-hosted runners is free and unlimited on public repositories. `macos-latest` is a standard runner, `apache/texera` is public, so the 10x is a billed-minutes rate for private repos and buys nothing here. Removed from the comment and from the matching description row in 8217f1e1.
   
   The bound that replaced it is the one you pointed at. `orgs/apache` reports the `enterprise` plan, and [Actions limits](https://docs.github.com/en/actions/reference/limits) gives that tier:
   
   | Bound | Enterprise |
   | --- | --- |
   | total concurrent jobs | 500 |
   | **concurrent macOS jobs** | **50** |
   
   macOS is the scarce one by an order of magnitude, and that 50 is shared across the whole `apache` org, not this repo. So a hung leg holds one of fifty slots every Apache project draws from for six hours — same case for the cap, without a cost that isn't ours to pay.
   
   ```
   - ... implicit 6h cap — billed at 10x on the macOS leg.
   + ... implicit 6h cap, holding one of the 50 concurrent macOS jobs
   + the whole `apache` org shares for that window.
   ```
   



##########
frontend/TESTING.md:
##########
@@ -47,6 +47,7 @@ For repo-wide testing philosophy (TDD, characterization tests, "every test must
 | Coverage                 | `@vitest/coverage-v8`                                                                                                                  |
 | Test setup               | `src/test-zone-setup.ts` wraps `it`/`test` in an Angular ProxyZone (Vitest does not provide one and Angular's `fakeAsync` requires it) |
 | Globals                  | `globals: true` in `vitest.config.ts`, so `describe / it / expect / vi / beforeEach` come from the runtime — no per-file imports       |
+| Timeouts                 | Raised over Vitest's defaults because macOS CI runners stall for seconds at a time (#6073, #7713). jsdom: 20s per test / 30s per hook (`vitest.config.ts`, defaults 5s/10s). Browser mode: 30s per test (`vitest.browser.config.ts`), hooks left at the 30s `browser.enabled` already resolves — its per-test default is 15s |

Review Comment:
   Taken verbatim in 8217f1e1 — `the 30s default that` gives the trailing clause its noun. Thanks for catching it.
   



-- 
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] fix(ci, test, frontend): stop the frontend matrix manufacturing false reds [texera]

Posted by "aglinxinyuan (via GitHub)" <gi...@apache.org>.

aglinxinyuan commented on PR #7623:
URL: https://github.com/apache/texera/pull/7623#issuecomment-5338318161

Conflict resolved, but it rescoped the PR — flagging that rather than burying it in a merge commit.

**#7717 landed the jsdom half two days ago** (`testTimeout: 20000`, `hookTimeout: 30000`), which is exactly what conflicted. My branch carried 30s/30s, so keeping mine would have reverted a value @mengw15 had just merged, with no argument for the change and inside a merge. I took main's verbatim instead — `git diff main -- frontend/vitest.config.ts` is now empty. If 20s turns out too tight for the test ceiling, that's a separate PR against a merged number, not a conflict resolution.

Two statements were true before #7717 and are not now, so both got rewritten:

- `vitest.browser.config.ts` justified `testTimeout: 30_000` as "the same 30s the jsdom config uses". jsdom is 20s. The standing argument is that browser mode's 15s default is now the *tightest* per-test ceiling in the job, sitting on the slower of its two runtimes.
- `TESTING.md` read "30s per test in both configs" under one shared provenance. Split per config against the post-#7717 values.

**Separately, I got the job cap wrong and it's now 45, not 30.** I sized 30 off run `31869822969` alone — legs at 8.6 / 10.0 / 10.7 min — and wrote "~3x the slowest". Pulling every frontend leg from the last eight `Required Checks` runs via the jobs API:

| Leg | green legs observed | worst green |
| --- | --- | --- |
| ubuntu-latest | 8.4 – 9.6 min | 9.6 min |
| windows-latest | 7.1 – 11.4 min | 11.4 min |
| macos-latest | 10.0 – 21.1 min | **21.1 min** |

The 21.1-minute one is run `32219352076` — this branch's own merge push, green. #7713 has the same range independently at 16m52s. So 30 was 1.4x the worst observed *passing* leg and could have ended a run that was only slow, which is the same false red the `fail-fast` opt-out is here to stop manufacturing. Per step, the variance is in `Prod build` (4.5 → 7.8 → 11.1 min on macOS) rather than the tests (4.4 → 5.3 min), so it's headroom for an Angular production build on a loaded runner, not for vitest.

Title and description updated to match — the PR is now `fail-fast: false` + the job cap + the browser-mode ceiling + the doc row, and `Closes #6073` still holds since #7717 took the jsdom follow-up and this takes the other two.

--
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] fix(test, frontend): raise Vitest timeouts for CI stalls [texera]

Posted by "codecov-commenter (via GitHub)" <gi...@apache.org>.

codecov-commenter commented on PR #7623:
URL: https://github.com/apache/texera/pull/7623#issuecomment-5276188643

   ## [Codecov](https://app.codecov.io/gh/apache/texera/pull/7623?dropdown=coverage&src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) Report
   :white_check_mark: All modified and coverable lines are covered by tests.
   :white_check_mark: Project coverage is 88.96%. Comparing base ([`dd7d813`](https://app.codecov.io/gh/apache/texera/commit/dd7d813e92e9194e96d74b6926e48065462901ca?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache)) to head ([`b3772da`](https://app.codecov.io/gh/apache/texera/commit/b3772da33f66a58bf8fb86af66783a1b3e537600?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache)).
   :warning: Report is 6 commits behind head on main.
   
   <details><summary>Additional details and impacted files</summary>
   
   
   
   ```diff
   @@            Coverage Diff            @@
   ##               main    #7623   +/-   ##
   =========================================
     Coverage     88.96%   88.96%           
     Complexity     4338     4338           
   =========================================
     Files          1178     1178           
     Lines         46835    46835           
     Branches       5226     5226           
   =========================================
     Hits          41667    41667           
     Misses         3422     3422           
     Partials       1746     1746           
   ```
   
   | [Flag](https://app.codecov.io/gh/apache/texera/pull/7623/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | Coverage Δ | | *Carryforward flag |
   |---|---|---|---|
   | [access-control-service](https://app.codecov.io/gh/apache/texera/pull/7623/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `70.00% <ø> (ø)` | | Carriedforward from [dd7d813](https://app.codecov.io/gh/apache/texera/commit/dd7d813e92e9194e96d74b6926e48065462901ca?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
   | [agent-service](https://app.codecov.io/gh/apache/texera/pull/7623/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `98.62% <ø> (ø)` | | |
   | [amber](https://app.codecov.io/gh/apache/texera/pull/7623/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `84.88% <ø> (ø)` | | Carriedforward from [dd7d813](https://app.codecov.io/gh/apache/texera/commit/dd7d813e92e9194e96d74b6926e48065462901ca?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
   | [computing-unit-managing-service](https://app.codecov.io/gh/apache/texera/pull/7623/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `60.38% <ø> (ø)` | | Carriedforward from [dd7d813](https://app.codecov.io/gh/apache/texera/commit/dd7d813e92e9194e96d74b6926e48065462901ca?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
   | [config-service](https://app.codecov.io/gh/apache/texera/pull/7623/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `77.31% <ø> (ø)` | | Carriedforward from [dd7d813](https://app.codecov.io/gh/apache/texera/commit/dd7d813e92e9194e96d74b6926e48065462901ca?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
   | [file-service](https://app.codecov.io/gh/apache/texera/pull/7623/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `68.90% <ø> (ø)` | | Carriedforward from [dd7d813](https://app.codecov.io/gh/apache/texera/commit/dd7d813e92e9194e96d74b6926e48065462901ca?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
   | [frontend](https://app.codecov.io/gh/apache/texera/pull/7623/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `90.57% <ø> (ø)` | | Carriedforward from [dd7d813](https://app.codecov.io/gh/apache/texera/commit/dd7d813e92e9194e96d74b6926e48065462901ca?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
   | [notebook-migration-service](https://app.codecov.io/gh/apache/texera/pull/7623/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `78.89% <ø> (ø)` | | Carriedforward from [dd7d813](https://app.codecov.io/gh/apache/texera/commit/dd7d813e92e9194e96d74b6926e48065462901ca?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
   | [pyamber](https://app.codecov.io/gh/apache/texera/pull/7623/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `97.52% <ø> (ø)` | | Carriedforward from [dd7d813](https://app.codecov.io/gh/apache/texera/commit/dd7d813e92e9194e96d74b6926e48065462901ca?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
   | [workflow-compiling-service](https://app.codecov.io/gh/apache/texera/pull/7623/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `57.89% <ø> (ø)` | | Carriedforward from [dd7d813](https://app.codecov.io/gh/apache/texera/commit/dd7d813e92e9194e96d74b6926e48065462901ca?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
   
   *This pull request uses carry forward flags. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) to find out more.
   </details>
   
   [:umbrella: View full report in Codecov by Harness](https://app.codecov.io/gh/apache/texera/pull/7623?dropdown=coverage&src=pr&el=continue&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache).   
   :loudspeaker: Have feedback on the report? [Share it here](https://about.codecov.io/codecov-pr-comment-feedback/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache).
   <details><summary> :rocket: New features to boost your workflow: </summary>
   
   - :package: [JS Bundle Analysis](https://docs.codecov.com/docs/javascript-bundle-analysis): Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
   </details>


-- 
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] fix(test, frontend): raise Vitest timeouts for CI stalls [texera]

Posted by "aglinxinyuan (via GitHub)" <gi...@apache.org>.

aglinxinyuan commented on code in PR #7623:
URL: https://github.com/apache/texera/pull/7623#discussion_r3793443347


##########
.github/workflows/build.yml:
##########
@@ -86,7 +86,20 @@ jobs:
   frontend:
     if: ${{ inputs.run_frontend }}
     runs-on: ${{ matrix.os }}
+    # Only the "Install dependency" step below is bounded, so a spec that
+    # truly hangs would otherwise run to GitHub's implicit 6h cap — billed at
+    # 10x on the macOS leg. Recent green runs take 4-12 minutes and install
+    # alone may take 20, so 30 bounds a hang while still absorbing a cold
+    # yarn cache on a slow runner.

Review Comment:
   Right on both counts, and I checked the numbers against the API rather than take them from the reply — run `31869822969`, per step:
   
   | Leg | Job | Install | Rest |
   | --- | --- | --- | --- |
   | ubuntu-latest | 8.6 min | 37s | 8.0 min |
   | macos-latest | 10.0 min | 49s | 9.2 min |
   | windows-latest | 10.7 min | 74s | 9.5 min |
   
   So the 20 was indeed the step's budget at `:142`, not an observation, and the absorption claim inverts: install at its full 20 would put windows at 29.5 against a 30 cap.
   
   Reworded in 2e68703 to size off the legs — 8.6-10.7 minutes end to end, install under 90s everywhere, so 30 is ~3x the slowest with ~19 minutes of slack. Kept the value at 30 as you suggested. I went with the measured range plus the install figure rather than the suggested wording, since naming install's real cost is what stops the next reader making the same 20-minute misread.



-- 
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] fix(ci, test, frontend): stop the frontend matrix manufacturing false reds [texera]

Posted by "Yicong-Huang (via GitHub)" <gi...@apache.org>.

Yicong-Huang commented on code in PR #7623:
URL: https://github.com/apache/texera/pull/7623#discussion_r3841395794


##########
.github/workflows/build.yml:
##########
@@ -86,7 +86,25 @@ jobs:
   frontend:
     if: ${{ inputs.run_frontend }}
     runs-on: ${{ matrix.os }}
+    # Only the "Install dependency" step below is bounded, so a spec that
+    # truly hangs would otherwise run to GitHub's implicit 6h cap, holding one
+    # of the 50 concurrent macOS jobs the whole `apache` org shares for that
+    # window. Sized off observed *green* legs rather than a typical one,

Review Comment:
   This fragment has no subject, and ‘sized off’ is non-idiomatic.
   ```suggestion
       # window. The timeout is based on observed *green* legs rather than a typical one,
   ```



-- 
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] fix(test, frontend): raise Vitest timeouts for CI stalls [texera]

Posted by "aglinxinyuan (via GitHub)" <gi...@apache.org>.

aglinxinyuan commented on code in PR #7623:
URL: https://github.com/apache/texera/pull/7623#discussion_r3788744914


##########
frontend/vitest.browser.config.ts:
##########
@@ -64,6 +64,11 @@ export default defineConfig({
     // browser-mode the runtime has neither, so we install the `buffer` npm
     // package as a shim).
     setupFiles: ["src/browser-buffer-polyfill.ts", "src/test-zone-setup.ts"],
+    // Same runner-stall headroom as the jsdom config (vitest.config.ts):
+    // driving a real Chromium through playwright is strictly slower than
+    // jsdom, so these specs need at least as much slack. See #6073.
+    testTimeout: 30_000,
+    hookTimeout: 30_000,

Review Comment:
   Addressed in fb5ec5a. Confirmed against the pinned 4.1.10 in `node_modules` (`vitest/dist/chunks/coverage.DM_a_rWm.js:538-539`) — with `browser.enabled` the defaults resolve to 15s test / 30s hook, so `hookTimeout: 30_000` was restating the default. Dropped it, and the comment now says what the remaining line actually does: a 15s -> 30s bump so the Chromium leg matches the jsdom ceiling.
   
   TESTING.md is scoped per config now: 30s per test in both (up from 5s under jsdom, 15s under `browser.enabled`), hooks 30s under jsdom (up from 10s) with browser mode already there by default.



##########
frontend/vitest.config.ts:
##########
@@ -34,6 +34,16 @@ 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"],
+    // Vitest defaults (5s per test, 10s per hook) are too tight for the
+    // macOS runners, which stall for seconds at a time under load: the same
+    // spec file that takes 240ms on ubuntu-latest has been observed taking
+    // 11.7s on macos-latest in the same commit's matrix. The stall lands on
+    // whichever test happens to be running, so raising the ceiling is the
+    // only fix that isn't whack-a-mole — three different specs have gone
+    // red this way. A test that legitimately needs >30s is broken, and the
+    // job's own timeout still bounds a true hang. See apache/texera#6073.

Review Comment:
   Addressed in fb5ec5a. Added `timeout-minutes: 30` to the `frontend` job, same as `amber-integration` does, so the sentence points at a real bound instead of the implicit 6h cap. Sizing: recent green legs run 4-12 min (this PR's own run was ubuntu 8, windows 11, macOS 12) and the "Install dependency" step is already allowed 20 on its own, so 30 bounds a hang while still absorbing a cold yarn cache on a slow runner. The vitest.config.ts comment now names that key explicitly.



##########
.github/workflows/build.yml:
##########
@@ -87,6 +87,12 @@ jobs:
     if: ${{ inputs.run_frontend }}
     runs-on: ${{ matrix.os }}
     strategy:
+      # An OS-specific failure should not cancel the other two legs: with the
+      # default fail-fast the surviving jobs report "The operation was
+      # canceled" and 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. Every other multi-leg matrix here already opts out.

Review Comment:
   You're right — I parsed the file rather than trust the claim: the jobs that set `fail-fast: false` are exactly `platform`, `platform-integration`, `agent-service` and `infra`, while `amber-integration` (2 OS legs) and `pyamber` (3 Python versions) are multi-leg with no opt-out. Fixed in fb5ec5a to name those four instead.
   
   On the aside: left `amber-integration` alone here to keep this PR to the frontend job — happy to open a follow-up for it and `pyamber`.



-- 
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] fix(ci, test, frontend): stop the frontend matrix manufacturing false reds [texera]

Posted by "aglinxinyuan (via GitHub)" <gi...@apache.org>.

aglinxinyuan commented on code in PR #7623:
URL: https://github.com/apache/texera/pull/7623#discussion_r3841599991


##########
.github/workflows/build.yml:
##########
@@ -86,7 +86,25 @@ jobs:
   frontend:
     if: ${{ inputs.run_frontend }}
     runs-on: ${{ matrix.os }}
+    # Only the "Install dependency" step below is bounded, so a spec that
+    # truly hangs would otherwise run to GitHub's implicit 6h cap, holding one
+    # of the 50 concurrent macOS jobs the whole `apache` org shares for that
+    # window. Sized off observed *green* legs rather than a typical one,

Review Comment:
   Both fair — fixed in 7b872d95. I took the wording and reflowed the paragraph rather than paste the line verbatim: the suggested line runs to 88 columns and this block wraps at 78, so the substance is yours, the wrapping is the block's.
   
   ```
   - # window. Sized off observed *green* legs rather than a typical one,
   + # window. The timeout is based on observed *green* legs rather than a
   + # typical one, ...
   ```
   
   Widest line in the block is now 78. Same idiom appeared twice in the description (the section heading and the sentence about the earlier `30`), so both say `based on` now too.
   
   Worth adding to the sizing evidence while it's here: the three legs on the previous head all went green at ubuntu 8m48s / windows 11m13s / macOS 15m14s — the macOS one lands mid-range against the 10.0-21.1 min band the comment is built on, so 45 still reads as ~2x the worst green leg rather than a number chosen once and left.
   



-- 
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] fix(test, frontend): raise Vitest timeouts for CI stalls [texera]

Posted by "Yicong-Huang (via GitHub)" <gi...@apache.org>.

Yicong-Huang commented on code in PR #7623:
URL: https://github.com/apache/texera/pull/7623#discussion_r3782721212


##########
frontend/vitest.config.ts:
##########
@@ -34,6 +34,16 @@ 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"],
+    // Vitest defaults (5s per test, 10s per hook) are too tight for the
+    // macOS runners, which stall for seconds at a time under load: the same
+    // spec file that takes 240ms on ubuntu-latest has been observed taking
+    // 11.7s on macos-latest in the same commit's matrix. The stall lands on
+    // whichever test happens to be running, so raising the ceiling is the
+    // only fix that isn't whack-a-mole — three different specs have gone
+    // red this way. A test that legitimately needs >30s is broken, and the
+    // job's own timeout still bounds a true hang. See apache/texera#6073.

Review Comment:
   Nothing backs this reassurance: the `frontend` job sets no `timeout-minutes` (the only one is on the "Install dependency" step, `build.yml:135`), so the bound is GitHub's implicit 6h default — billed 10x on macOS. Literally true, misleading in the way that matters. Two jobs down, `amber-integration` (`build.yml:366-370`) sets `timeout-minutes: 25` rather than rely on the cap. Adding the same key here (green runs are 8-13 min) makes the sentence carry its weight.



##########
.github/workflows/build.yml:
##########
@@ -87,6 +87,12 @@ jobs:
     if: ${{ inputs.run_frontend }}
     runs-on: ${{ matrix.os }}
     strategy:
+      # An OS-specific failure should not cancel the other two legs: with the
+      # default fail-fast the surviving jobs report "The operation was
+      # canceled" and 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. Every other multi-leg matrix here already opts out.

Review Comment:
   Refuted twice in this same file: `amber-integration` (`:378-380`, `os: [ubuntu-latest, macos-latest]`) and `pyamber` (`:1038-1040`, three Python versions) are both multi-leg with no `fail-fast` key. The set that actually opts out is `platform`, `platform-integration`, `agent-service`, and `infra` — naming those keeps it true. (Aside for a follow-up: `amber-integration` runs macOS beside ubuntu with no opt-out, so this cancellation still applies there.)



##########
frontend/vitest.browser.config.ts:
##########
@@ -64,6 +64,11 @@ export default defineConfig({
     // browser-mode the runtime has neither, so we install the `buffer` npm
     // package as a shim).
     setupFiles: ["src/browser-buffer-polyfill.ts", "src/test-zone-setup.ts"],
+    // Same runner-stall headroom as the jsdom config (vitest.config.ts):
+    // driving a real Chromium through playwright is strictly slower than
+    // jsdom, so these specs need at least as much slack. See #6073.
+    testTimeout: 30_000,
+    hookTimeout: 30_000,

Review Comment:
   Vitest resolves timeout defaults from `browser.enabled`, which this config sets `true`. In the pinned 4.1.10 (`vitest/dist/chunks/coverage.DM_a_rWm.js:538-539`): `hookTimeout ??= browser.enabled ? 3e4 : 1e4`, `testTimeout ??= browser.enabled ? 15e3 : 5e3`. So the real defaults here are already 15s/30s — `hookTimeout: 30_000` just restates the default, and `testTimeout` is a 2x bump, not 6x. That also makes TESTING.md's "raised from the 5s/10s defaults" wrong for the browser leg (right for jsdom). Suggest dropping this line and scoping the doc row per-config.



-- 
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org