What happened?
build / frontend (macos-latest) fails intermittently on pull requests that touch no frontend code at all, with a 20 s per-test timeout in workflow-execution-history.component.spec.ts. Seen on #8096, a CI-only change: four runs of that branch passed and the fifth failed, while ubuntu and windows passed every time.
FAIL gui src/app/dashboard/component/user/user-workflow/ngbd-modal-workflow-executions/workflow-execution-history.component.spec.ts
> WorkflowExecutionHistoryComponent > template-driven interactions
> bookmarks the whole selection from the card's group action
Error: Test timed out in 20000ms.
Test Files 1 failed | 208 passed (209)
Tests 1 failed | 5341 passed | 1 skipped (5343)
That test's body is three synchronous assertions, so the time goes into setup(). setup() attaches the fixture to document.body and calls detectChanges(), which runs ngAfterViewInit and with it two calls to the real Plotly.newPlot (workflow-execution-history.component.ts:280 and :318, via import * as Plotly from "plotly.js-basic-dist-min"). Plotly is not stubbed anywhere in the spec, and 36 of the file's 61 tests call setup() — roughly 72 real Plotly renders through jsdom per run.
Measured locally (node 24.19.0, jsdom):
|
tests |
total |
| as-is |
4.12 s |
5.87 s |
with vi.mock("plotly.js-basic-dist-min") |
1.91 s |
3.39 s |
So real Plotly is more than half this file's runtime, and exactly one of the 61 tests needs it: draws a username pie, a status pie, and a process-time bar chart, which reads data/layout back off the graph div that Plotly populates.
Locally the whole file passes in seconds, so this is not a hard failure — it is a per-test budget that shrinks under contention on the macOS runner. Removing the dominant avoidable cost is the fix; it is not proof that Plotly is the only contributor.
Suggested fix: stub Plotly.newPlot for the spec, and rewrite the one chart test to assert on the arguments the component passes to newPlot rather than on the DOM Plotly builds from them — which also tests the component's own decision rather than Plotly's rendering.
This is a recurrence rather than a new problem: #6541 / #6542 stabilised this same file's Plotly tests in July. #7966 later reworked the spec to render the table instead of calling handlers directly, which raised the setup() count and brought the cost back.
How to reproduce?
The CI failure is intermittent, so the cost is what reproduces deterministically:
cd frontend && yarn install with node 24.19.0.yarn ng test --watch=false --include "src/app/dashboard/component/user/user-workflow/ngbd-modal-workflow-executions/workflow-execution-history.component.spec.ts" and note the reported test time (~4.1 s for 61 tests).- Insert
vi.mock("plotly.js-basic-dist-min", () => ({ newPlot: vi.fn() })); after the imports and re-run: test time drops to ~1.9 s, and exactly one test fails — the chart test that asserts on Plotly's DOM side effect.
Note: frontend/TESTING.md documents ng test --test-file <path> for single-file runs, but the builder rejects that argument; the current flag is --include.
Version/Branch
main
What happened?
build / frontend (macos-latest)fails intermittently on pull requests that touch no frontend code at all, with a 20 s per-test timeout inworkflow-execution-history.component.spec.ts. Seen on #8096, a CI-only change: four runs of that branch passed and the fifth failed, while ubuntu and windows passed every time.That test's body is three synchronous assertions, so the time goes into
setup().setup()attaches the fixture todocument.bodyand callsdetectChanges(), which runsngAfterViewInitand with it two calls to the realPlotly.newPlot(workflow-execution-history.component.ts:280and:318, viaimport * as Plotly from "plotly.js-basic-dist-min"). Plotly is not stubbed anywhere in the spec, and 36 of the file's 61 tests callsetup()— roughly 72 real Plotly renders through jsdom per run.Measured locally (node 24.19.0, jsdom):
vi.mock("plotly.js-basic-dist-min")So real Plotly is more than half this file's runtime, and exactly one of the 61 tests needs it:
draws a username pie, a status pie, and a process-time bar chart, which readsdata/layoutback off the graph div that Plotly populates.Locally the whole file passes in seconds, so this is not a hard failure — it is a per-test budget that shrinks under contention on the macOS runner. Removing the dominant avoidable cost is the fix; it is not proof that Plotly is the only contributor.
Suggested fix: stub
Plotly.newPlotfor the spec, and rewrite the one chart test to assert on the arguments the component passes tonewPlotrather than on the DOM Plotly builds from them — which also tests the component's own decision rather than Plotly's rendering.This is a recurrence rather than a new problem: #6541 / #6542 stabilised this same file's Plotly tests in July. #7966 later reworked the spec to render the table instead of calling handlers directly, which raised the
setup()count and brought the cost back.How to reproduce?
The CI failure is intermittent, so the cost is what reproduces deterministically:
cd frontend && yarn installwith node 24.19.0.yarn ng test --watch=false --include "src/app/dashboard/component/user/user-workflow/ngbd-modal-workflow-executions/workflow-execution-history.component.spec.ts"and note the reported test time (~4.1 s for 61 tests).vi.mock("plotly.js-basic-dist-min", () => ({ newPlot: vi.fn() }));after the imports and re-run: test time drops to ~1.9 s, and exactly one test fails — the chart test that asserts on Plotly's DOM side effect.Note:
frontend/TESTING.mddocumentsng test --test-file <path>for single-file runs, but the builder rejects that argument; the current flag is--include.Version/Branch
main