Area for Improvement
Reliability of the Jest test suite under parallel execution.
Observed behavior
Five page test suites intermittently exceed Jest's 5000 ms default timeout when the suite is run with full parallelism:
EnvironmentListPageApplicationListPageResourceTypesListPageResourceTypeDetailPageResourcePage
Each one passes reliably when run in isolation, and the whole suite passes reliably at --maxWorkers=2. Observed on a machine with roughly 67% baseline CPU load from unrelated applications, so the trigger is contention rather than anything in the tests themselves.
Two things make this more than ordinary flakiness:
It reports the wrong cause. Now that coverage floors are enforced, a timed-out suite executes less code and therefore lowers measured coverage. The run then fails on a coverage threshold, naming a path group, rather than on the timeout that actually caused it. Observed concretely: branches 30.72% vs 31% floor, with the real problem being two suites that never finished. Anyone debugging that failure starts in the wrong place.
The underlying fact is worth knowing. A single page render taking multiple seconds under load is itself information. Raising the timeout would make the gate trustworthy and simultaneously hide that signal.
Desired behavior
The suite passes deterministically at default parallelism on a loaded machine, and a timeout is reported as a timeout.
Proposed Fix
Deliberately not fixed yet, and the reasoning is worth recording rather than just the fix.
The test plan these suites belong to freezes existing behavior in its early phases specifically so that later rearchitecture can be verified against it. Changing the test harness during that window is the same category of change the plan forbids elsewhere — it would alter the baseline at the moment the baseline is supposed to be stable.
Options, in preference order:
- Leave it until Phase 1 rewrites those five suites, since they are on the list to be replaced anyway, and treat any occurrence in CI before then as a fix-immediately signal. This is the current recommendation.
- Raise
testTimeout for those suites specifically, accepting that it masks the render cost.
- Investigate why a single page render takes seconds under load. Most valuable, least urgent.
Interim workaround for local runs: yarn test:all --maxWorkers=2.
Additional context
Recorded as "Known flakiness in the existing suite" and as open decision 7 in docs/design/2026-09-dashboard-plugin-test-plan.md.
Not observed failing in CI to date — the GitHub-hosted runner is not under the same background load. Filing it before it does, because the coverage-threshold misattribution above makes it unusually confusing to diagnose cold.
Area for Improvement
Reliability of the Jest test suite under parallel execution.
Observed behavior
Five page test suites intermittently exceed Jest's 5000 ms default timeout when the suite is run with full parallelism:
EnvironmentListPageApplicationListPageResourceTypesListPageResourceTypeDetailPageResourcePageEach one passes reliably when run in isolation, and the whole suite passes reliably at
--maxWorkers=2. Observed on a machine with roughly 67% baseline CPU load from unrelated applications, so the trigger is contention rather than anything in the tests themselves.Two things make this more than ordinary flakiness:
It reports the wrong cause. Now that coverage floors are enforced, a timed-out suite executes less code and therefore lowers measured coverage. The run then fails on a coverage threshold, naming a path group, rather than on the timeout that actually caused it. Observed concretely:
branches 30.72% vs 31% floor, with the real problem being two suites that never finished. Anyone debugging that failure starts in the wrong place.The underlying fact is worth knowing. A single page render taking multiple seconds under load is itself information. Raising the timeout would make the gate trustworthy and simultaneously hide that signal.
Desired behavior
The suite passes deterministically at default parallelism on a loaded machine, and a timeout is reported as a timeout.
Proposed Fix
Deliberately not fixed yet, and the reasoning is worth recording rather than just the fix.
The test plan these suites belong to freezes existing behavior in its early phases specifically so that later rearchitecture can be verified against it. Changing the test harness during that window is the same category of change the plan forbids elsewhere — it would alter the baseline at the moment the baseline is supposed to be stable.
Options, in preference order:
testTimeoutfor those suites specifically, accepting that it masks the render cost.Interim workaround for local runs:
yarn test:all --maxWorkers=2.Additional context
Recorded as "Known flakiness in the existing suite" and as open decision 7 in
docs/design/2026-09-dashboard-plugin-test-plan.md.Not observed failing in CI to date — the GitHub-hosted runner is not under the same background load. Filing it before it does, because the coverage-threshold misattribution above makes it unusually confusing to diagnose cold.