Browser tests: wait for the page's state, not for a fixed time #723
Labels
No labels
accessibility
authentication
breaking change
bug
documentation
enhancement
interface
internationalisation
observability
performance
security
tier
1
tier
2
tier
3
tier/4
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
Postulo/postulo#723
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Measured from Forgejo's task API and job logs, runs 561–710 (24 Sep – 4 Oct 2026): wall time per push about 52–55 min, up from about 15; the browser suite grew from 149 to 645 tests in five days and runs serially (29 min); the runner takes two jobs at a time, in the order the workflow file lists them, so the browser job starts 19–22 min after the push; and Forgejo cancels the older push run when a newer push lands, which stopped 18 of 56 browser jobs before they gave a verdict.
There are 54
wait_for_timeoutcalls in 14 browser test files (test_board_fold.py16,test_help.py13,test_navigation_bar.py6), about 17 seconds of literal waiting before parametrisation multiplies it. A fixed wait is too long on a quiet machine and too short on a loaded one.Proposal
expecton X.test_board_fold.py(:376,:1128,:1217), moves to Playwright'spage.clockwhere the page's timers allow it, or stays with a comment saying why.Done when
wait_for_timeoutcarries a comment saying what time it measures.