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.
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
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Observed once during the work on #161:
page.reload()on a popup with in-flight balance fetches producedconsole.error: [AutistMask] loadHomeTxs failed: Failed to fetch, whichtests/e2e/harness.jscounts 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:
Implementation requirements
Definition of done
tests/e2e/harness.jsdocuments why it is benign and does not count it.loadHomeTxsfailure still fails the run.TODO.mdupdated in the same commit.make checkpasses.Reproduced by reloading the popup mid-refresh. Chrome fires
pagehideon the old page and then cancels its open requests; each fails in the page with "Failed to fetch", andloadHomeTxs,fetchTokenBalancesand 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