Repository navigation
fix: the browser suite gets the wait budget a loaded runner needs - #18
Merged
Merged
Conversation
…waits too The runner is two cores and the whole browser suite starts a browser per test file. Four push runs failed on waits with a ten second budget: the page title at 10.6 s, 'held back', and one layout read taken before the dock had settled. The budget only decides how long a wait that is going to fail takes to fail.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Four of today's push runs failed on waits with a ten second budget, on a runner with two cores that starts a browser per test file:
Timed out waiting for the title(10.6 s to answer, timeout at 13.9 s)Timed out waiting for held backWhat changed
test/helpers.ts:until's default budget is thirty seconds instead of ten. It only decides how long a wait that is going to fail takes to fail; a wait that succeeds still returns on the first poll that sees it.test/browser.test.ts: the two title waits now use that default, so the reason lives in one place.test/subagents-ui.test.ts: the dock's unfolded state is a bounded wait rather than a single read. The assertion still fails if the state never arrives.Proof
npm test: 640 tests, 640 pass, 0 fail, 0 skipped, 75 s.node --test test/subagents-ui.test.ts: 23 pass, 0 fail.npm run check,npm run lint,npm run format:check: exit 0.