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:49 UTC

Re: [I] Flaky frontend unit test: joint-ui.service per-port counts test times out on Windows CI [texera]

aglinxinyuan commented on issue #6073:
URL: https://github.com/apache/texera/issues/6073#issuecomment-5276184265

   It re-fired — three more times in the last four days, all on the **macOS** leg rather than Windows:
   
   | 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` |
   
   Three different specs, so this confirms the original read: the runner stalls and the stall lands on whichever test happens to be executing. Numbers from run `31665399757` — one commit, one matrix:
   
   | 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 |
   
   The same file took 219 ms on macOS in an earlier run and 443 ms locally, so it isn't systematically slow — the 11.7 s is the stall. jsdom + v8-coverage workers on 3 cores / 7 GB run under real memory pressure, which is the likely source of the multi-second pauses.
   
   Both follow-ups listed above are now up in #7623 (30 s `testTimeout`/`hookTimeout`, and `fail-fast: false` on the frontend matrix so one flaky OS stops cancelling the other two legs). Leaving this issue open and assigned to @rbelavadi — the third suggestion, collecting occurrences, is what the table above is for, and capping `maxWorkers` on the macOS leg is still unexplored if the flake survives the timeout bump.
   


-- 
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