test: the e2e suite waits for each save before it closes the popup (closes #446)
The Settings round trip switched the theme and the network and closed the popup at once. A close before the change handler's save lands loses the switch, and the suite then ran on Sepolia. tests/e2e/run.js now has one helper that polls a field of the stored record until it holds the expected value, in place of the wait that only read viewStack. Each Settings switch and spam-filter toggle waits for its save, the recovery-phrase reopen waits for its saved view, and reopenPopup() waits until the view it expects to reopen on is the saved one. README.md no longer lists #446 among the open reports of the Chrome suite failing under load. Model: opus-5-5
This commit is contained in:
@@ -619,15 +619,13 @@ The jobs **report, they do not gate.** A failure is a red mark against the
|
||||
commit that a reviewer has to account for, not a hard block: whether a check
|
||||
blocks a merge is Gitea branch protection, which this repo does not configure.
|
||||
|
||||
That is not only a statement about configuration. Reports of the Chrome suite
|
||||
**failing under load** are still open, among them
|
||||
That is not only a statement about configuration. A report of the Chrome suite
|
||||
**failing under load** is still open:
|
||||
[#290](https://git.eeqj.de/sneak/AutistMask/issues/290), runs on a busy machine
|
||||
failing with `the extension opened no approval window within 30000ms`, and
|
||||
[#446](https://git.eeqj.de/sneak/AutistMask/issues/446), the Settings round trip
|
||||
closing the popup before its network switch is saved. So a red `e2e-chrome` has
|
||||
to be read before it is believed, and those failures are the blocker to ever
|
||||
making this a required check. Do not answer them with a retry wrapper: a suite
|
||||
that reruns until it is green stops being evidence.
|
||||
failing with `the extension opened no approval window within 30000ms`. So a red
|
||||
`e2e-chrome` has to be read before it is believed, and those failures are the
|
||||
blocker to ever making this a required check. Do not answer them with a retry
|
||||
wrapper: a suite that reruns until it is green stops being evidence.
|
||||
|
||||
Nothing in either job can pass vacuously. There is no `continue-on-error` and no
|
||||
`|| true`; both scripts exit non-zero when docker is missing, when the image
|
||||
|
||||
Reference in New Issue
Block a user