test: popup reload mid-refresh can fail the e2e run with "loadHomeTxs failed: Failed to fetch" #218

New Issue

2026-08-11T14:40:59+02:00

clawbot commented

2026-08-11 14:40:59 +02:00

Observed once during the work on #161: page.reload() on a popup with in-flight balance fetches produced console.error: [AutistMask] loadHomeTxs failed: Failed to fetch, which tests/e2e/harness.js counts as a run failure.

Not reproduced deliberately, and not in that issue's scope. Filing it because an e2e suite that can go red for a reason unrelated to the change under test will burn review cycles and, worse, train people to re-run until green.

Two possible outcomes and both are fine — the point is to establish which:

It is a real defect: a popup reloaded mid-refresh surfaces a fetch error to the user for a request that was simply cancelled. Then the fix is to distinguish an aborted in-flight request from a genuine failure and not log or render it as an error.
It is benign teardown noise. Then the harness should say so explicitly rather than counting it.

Implementation requirements

Reproduce deliberately first: reload the popup mid-refresh repeatedly until it fires. Do not "fix" it on the strength of a single sighting.
If it is an aborted-request artifact, distinguish abort from failure at the source rather than filtering the string in the harness — a substring filter would also swallow a real fetch failure.

Definition of done

The behaviour is reproduced deliberately and its cause identified.
Either the error no longer occurs for a cancelled in-flight request, or tests/e2e/harness.js documents why it is benign and does not count it.
Whichever way it goes, a real loadHomeTxs failure still fails the run.
TODO.md updated in the same commit.
make check passes.

Observed once during the work on https://git.eeqj.de/sneak/AutistMask/issues/161: `page.reload()` on a popup with in-flight balance fetches produced `console.error: [AutistMask] loadHomeTxs failed: Failed to fetch`, which `tests/e2e/harness.js` counts as a run failure. Not reproduced deliberately, and not in that issue's scope. Filing it because an e2e suite that can go red for a reason unrelated to the change under test will burn review cycles and, worse, train people to re-run until green. Two possible outcomes and both are fine — the point is to establish which: - It is a real defect: a popup reloaded mid-refresh surfaces a fetch error to the user for a request that was simply cancelled. Then the fix is to distinguish an aborted in-flight request from a genuine failure and not log or render it as an error. - It is benign teardown noise. Then the harness should say so explicitly rather than counting it. ## Implementation requirements - Reproduce deliberately first: reload the popup mid-refresh repeatedly until it fires. Do not "fix" it on the strength of a single sighting. - If it is an aborted-request artifact, distinguish abort from failure at the source rather than filtering the string in the harness — a substring filter would also swallow a real fetch failure. ## Definition of done - [ ] The behaviour is reproduced deliberately and its cause identified. - [ ] Either the error no longer occurs for a cancelled in-flight request, or `tests/e2e/harness.js` documents why it is benign and does not count it. - [ ] Whichever way it goes, a real `loadHomeTxs` failure still fails the run. - [ ] `TODO.md` updated in the same commit. - [ ] `make check` passes.

clawbot referenced this issue

2026-08-14 06:26:15 +02:00

test: make test-e2e is flaky under host load — "the extension opened no approval window within 30000ms" #290

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/AutistMask#218