Flaky frontend unit test: joint-ui.service per-port counts test times out on Windows CI

[aglinxinyuan]

What happened?

The build / frontend (windows-latest) CI job failed on #6068 — a yarn.lock-only Dependabot bump that touches no runtime code — because one frontend unit test hit the 5s timeout. Expected: the test passes; it is fully synchronous (builds a mocked JointJS paper out of vi.fn() spies, calls changeOperatorStatistics(...) directly, and asserts on the spy calls), so there is no async work that could legitimately take 5 seconds. The timeout means the Windows runner stalled mid-test — a flake, not a regression. The identical commit passed on rerun with no changes.

Failing run	https://github.com/apache/texera/actions/runs/28620556420/job/84875025428
Test	frontend/src/app/workspace/service/joint-ui/joint-ui.service.spec.ts (writes per-port counts derived from inputPortMetrics and outputPortMetrics)
Outcome	1 failed / 1272 passed; rerun of the same commit passed

flaky windows test (5s stall)
        │
        ▼
build / frontend (windows) fails
        │  fail-fast
        ▼
ubuntu + macos jobs cancelled mid-run → whole matrix red

Possible follow-ups:

• Bump vitest testTimeout (globally or Windows-only) to absorb runner stalls
• Set fail-fast: false on the frontend matrix so one flaky OS doesn't cancel the other two
• Collect further occurrences here if it re-fires

How to reproduce?

Not deterministically reproducible — this is a CI flake. It occurred on the frontend unit-test step (Run frontend unit tests) of the Required Checks workflow on windows-latest; rerunning the same commit passed. Watch for recurrences of the same test timing out on the Windows matrix leg.

Version/Branch

1.3.0-incubating-SNAPSHOT (main)

Commit Hash (Optional)

a43c5b1 (head of #6068, base 24b587f on main)

What browsers are you seeing the problem on?

No response

Relevant log output

FAIL  gui  src/app/workspace/service/joint-ui/joint-ui.service.spec.ts > JointUIService > changeOperatorStatistics > writes per-port counts derived from inputPortMetrics and outputPortMetrics
Error: Test timed out in 5000ms.

Test Files  1 failed | 122 passed | 1 skipped (124)
     Tests  1 failed | 1272 passed | 2 skipped | 1 todo (1276)

NX  Running target test for project gui failed

[rbelavadi]

/take

[aglinxinyuan]

It re-fired — three more times in the last four days, all on the macOS leg rather than Windows:

Run	Test	Error
31665399757	UserDatasetVersionCreatorComponent > onClickCreate creates a dataset with a sanitized name …	Test timed out in 5000ms
31630884042	AdminUserComponent > sortByAffiliation compares affiliations …	Hook timed out in 10000ms
31411656559	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.