flake: the Chrome e2e dApp signing prompt loses its page about one run in three under load #287

New Issue

clawbot · 2026-08-14T06:23:01+02:00

clawbot commented

2026-08-14 06:23:01 +02:00

Measured while wiring the suites into CI for #259. script/test-e2e was run six times against unmutated next code on this host, which is running many concurrent agent sessions. Two of the six failed, both identically, and a seventh run with an unrelated deliberate mutation hit the same fault at eth_signTypedData_v4. Nothing about the wallet changed between runs.

ok 30 - eth_requestAccounts approved returns the selected address (#183)
not ok 31 - personal_sign signs, and the signature recovers to the address (#183)
  page.waitForSelector: Target page, context or browser has been closed
Call log:
  - waiting for locator('#view-approve-sign') to be visible
    - locator resolved to hidden &lt;div class="view hidden" id="view-approve-sign"&gt;…&lt;/div&gt;

The approval popup page is found, #view-approve-sign is resolved but still hidden, and then the page or context goes away underneath the wait rather than the view becoming visible. It is a race between the harness's wait and the approval window's lifecycle, not a timeout: the message is "has been closed", not "exceeded".

The follow-on failure is not a second flake, it is the anti-vacuity guard doing its job — one approval never happened, so it counted two where three were signed:

not ok 37 - the password never crossed either boundary in this section (#183)
  fewer popup-to-background messages were observed than the three approvals that were signed: 2

Why this needs an owner now rather than later: #259 puts this suite on every push. A job that goes red about one run in three without a regression is the thing that teaches people to ignore red. That is why those jobs report rather than gate, and it is the single blocker to ever making e2e-chrome a required check.

Not diagnosed further here, and deliberately not papered over — no retry wrapper, no longer timeout, no downgraded assertion. The right fix is to find what closes that page and wait on the right signal.

Reproduce: make test-e2e in a loop on a loaded machine; expect roughly one failure in three, always in the #183 dApp section.

Measured while wiring the suites into CI for https://git.eeqj.de/sneak/AutistMask/issues/259. `script/test-e2e` was run six times against unmutated `next` code on this host, which is running many concurrent agent sessions. **Two of the six failed**, both identically, and a seventh run with an unrelated deliberate mutation hit the same fault at `eth_signTypedData_v4`. Nothing about the wallet changed between runs. ok 30 - eth_requestAccounts approved returns the selected address (#183) not ok 31 - personal_sign signs, and the signature recovers to the address (#183) page.waitForSelector: Target page, context or browser has been closed Call log: - waiting for locator('#view-approve-sign') to be visible - locator resolved to hidden <div class="view hidden" id="view-approve-sign">…</div> The approval popup page is found, `#view-approve-sign` is resolved but still hidden, and then the page or context goes away underneath the wait rather than the view becoming visible. It is a race between the harness's wait and the approval window's lifecycle, not a timeout: the message is "has been closed", not "exceeded". The follow-on failure is not a second flake, it is the anti-vacuity guard doing its job — one approval never happened, so it counted two where three were signed: not ok 37 - the password never crossed either boundary in this section (#183) fewer popup-to-background messages were observed than the three approvals that were signed: 2 Why this needs an owner now rather than later: https://git.eeqj.de/sneak/AutistMask/issues/259 puts this suite on every push. A job that goes red about one run in three without a regression is the thing that teaches people to ignore red. That is why those jobs report rather than gate, and it is the single blocker to ever making `e2e-chrome` a required check. Not diagnosed further here, and deliberately not papered over — no retry wrapper, no longer timeout, no downgraded assertion. The right fix is to find what closes that page and wait on the right signal. Reproduce: `make test-e2e` in a loop on a loaded machine; expect roughly one failure in three, always in the `#183` dApp section.

clawbot referenced this issue from a commit