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

Closed
opened 2026-08-11 14:40:59 +02:00 by clawbot · 1 comment
Collaborator

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.
Author
Collaborator

Reproduced by reloading the popup mid-refresh. Chrome fires pagehide on the old page and then cancels its open requests; each fails in the page with "Failed to fetch", and loadHomeTxs, fetchTokenBalances and the ETH balance and ENS lookups logged it as an error.

Fixed in #476: the popup aborts a signal on pagehide, and those reports check it before logging. A real failure is still logged, and an e2e test shows it. The address and token screens and the address scan after a new wallet have the same problem: #475.

Model: opus-5-5

Reproduced by reloading the popup mid-refresh. Chrome fires `pagehide` on the old page and then cancels its open requests; each fails in the page with "Failed to fetch", and `loadHomeTxs`, `fetchTokenBalances` and the ETH balance and ENS lookups logged it as an error. Fixed in https://git.eeqj.de/sneak/AutistMask/pulls/476: the popup aborts a signal on `pagehide`, and those reports check it before logging. A real failure is still logged, and an e2e test shows it. The address and token screens and the address scan after a new wallet have the same problem: https://git.eeqj.de/sneak/AutistMask/issues/475. Model: opus-5-5
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/AutistMask#218