Four end-to-end specs failed on a pull request that changes only Kotlin in the cohort module and touches no frontend file at all. A re-run of the same commit passed, so all four are flakes rather than breakage.
The four:
committee-save.spec.ts:24 (mobile-chrome, twice)member-manager-virtualization.spec.ts:57 (mobile-chrome, twice)board-slice-open.motion.spec.ts:269esports-season-drag.motion.spec.ts:334
The one I can account for
committee-save.spec.ts deliberately holds GET /users back by 3000ms, to reproduce the race #1042 was about, then waits for the PUT /committees/900 its click should send. That wait is legitimate — the request is the evidence, which is the distinction #1135 drew when it removed the response waits that were merely restating the next assertion.
The trouble is the budget. The wait uses the 5000ms default, and the spec spends 3000ms of it on its own delay before the click can even happen, leaving about two seconds for a page load, a form fill and a submit. On a loaded runner that is not enough, and the failure is TimeoutError: page.waitForRequest: Timeout 5000ms exceeded.
A spec that manufactures a delay should budget for it explicitly rather than inheriting a default sized for a page that is not being held back.
The other three
No diagnosis offered. member-manager-virtualization failed only on mobile-chrome, and the two motion specs are in the family #1148 and #1151 have been addressing. Recording them here so the pattern is visible rather than guessing at a shared cause — #1141 is the standing reminder that failures which look alike usually are not.
Acceptance criteria
Four end-to-end specs failed on a pull request that changes only Kotlin in the
cohortmodule and touches no frontend file at all. A re-run of the same commit passed, so all four are flakes rather than breakage.The four:
committee-save.spec.ts:24(mobile-chrome, twice)member-manager-virtualization.spec.ts:57(mobile-chrome, twice)board-slice-open.motion.spec.ts:269esports-season-drag.motion.spec.ts:334The one I can account for
committee-save.spec.tsdeliberately holdsGET /usersback by 3000ms, to reproduce the race #1042 was about, then waits for thePUT /committees/900its click should send. That wait is legitimate — the request is the evidence, which is the distinction #1135 drew when it removed the response waits that were merely restating the next assertion.The trouble is the budget. The wait uses the 5000ms default, and the spec spends 3000ms of it on its own delay before the click can even happen, leaving about two seconds for a page load, a form fill and a submit. On a loaded runner that is not enough, and the failure is
TimeoutError: page.waitForRequest: Timeout 5000ms exceeded.A spec that manufactures a delay should budget for it explicitly rather than inheriting a default sized for a page that is not being held back.
The other three
No diagnosis offered.
member-manager-virtualizationfailed only on mobile-chrome, and the two motion specs are in the family #1148 and #1151 have been addressing. Recording them here so the pattern is visible rather than guessing at a shared cause — #1141 is the standing reminder that failures which look alike usually are not.Acceptance criteria
committee-save.spec.tspasses repeatedly under load