Raised by the code read on #507 and not yet tried in a browser.
Where.pendingApprovals in src/background/index.js (line 67) is a module-level object holding every approval waiting for the user, with the site's unanswered request. README Background scheduling: Chrome stops the background worker after about 30 seconds idle, and module-level variables do not survive. #526 shows this already happens to connectedSites.
What may happen. A user who takes longer than the idle spell to read a transaction or signature approval presses Approve, and the background no longer knows the request: the approval is lost, and the site waits for an answer that never comes, or gets an error.
Should. README TxApproval and SignApproval: the request is answered when the user approves, rejects or closes the window, however long they take.
Severity: major
Definition of done
In the Chrome container, a test opens a transaction approval and a signature approval, stops the background worker while each is open (or waits past the idle timeout), then approves; the site receives the result. The outcome is stated on this issue.
If approvals are lost, the fix keeps them answerable however long the user takes, and that test is part of make test-e2e. If they are not lost, the test still lands, and this issue closes with it.
Model: opus-5-5
Raised by the code read on https://git.eeqj.de/sneak/AutistMask/issues/507 and not yet tried in a browser.
**Where.** `pendingApprovals` in `src/background/index.js` (line 67) is a module-level object holding every approval waiting for the user, with the site's unanswered request. README Background scheduling: Chrome stops the background worker after about 30 seconds idle, and module-level variables do not survive. https://git.eeqj.de/sneak/AutistMask/issues/526 shows this already happens to `connectedSites`.
**What may happen.** A user who takes longer than the idle spell to read a transaction or signature approval presses Approve, and the background no longer knows the request: the approval is lost, and the site waits for an answer that never comes, or gets an error.
**Should.** README TxApproval and SignApproval: the request is answered when the user approves, rejects or closes the window, however long they take.
Severity: major
## Definition of done
- [ ] In the Chrome container, a test opens a transaction approval and a signature approval, stops the background worker while each is open (or waits past the idle timeout), then approves; the site receives the result. The outcome is stated on this issue.
- [ ] If approvals are lost, the fix keeps them answerable however long the user takes, and that test is part of `make test-e2e`. If they are not lost, the test still lands, and this issue closes with it.
Model: opus-5-5
clawbot
self-assigned this 2026-10-14 06:32:17 +02:00
Yes, they are lost. In the Chrome container, with nothing attached to the background worker, an open signature approval kept the worker running for only about six minutes; Chrome then stopped it, and approving afterwards left the site's request unanswered while the window said the request can no longer be signed. Stopping the worker through the DevTools protocol loses a transaction approval the same way.
Model: opus-5-5
Yes, they are lost. In the Chrome container, with nothing attached to the background worker, an open signature approval kept the worker running for only about six minutes; Chrome then stopped it, and approving afterwards left the site's request unanswered while the window said the request can no longer be signed. Stopping the worker through the DevTools protocol loses a transaction approval the same way.
Model: opus-5-5
#553: the approval window now keeps the background worker running for as long as it is open, and make test-e2e leaves a transaction and a signature approval open for seven minutes and requires the site to receive both results.
Model: opus-5-5
https://git.eeqj.de/sneak/AutistMask/pulls/553: the approval window now keeps the background worker running for as long as it is open, and `make test-e2e` leaves a transaction and a signature approval open for seven minutes and requires the site to receive both results.
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.
Raised by the code read on #507 and not yet tried in a browser.
Where.
pendingApprovalsinsrc/background/index.js(line 67) is a module-level object holding every approval waiting for the user, with the site's unanswered request. README Background scheduling: Chrome stops the background worker after about 30 seconds idle, and module-level variables do not survive. #526 shows this already happens toconnectedSites.What may happen. A user who takes longer than the idle spell to read a transaction or signature approval presses Approve, and the background no longer knows the request: the approval is lost, and the site waits for an answer that never comes, or gets an error.
Should. README TxApproval and SignApproval: the request is answered when the user approves, rejects or closes the window, however long they take.
Severity: major
Definition of done
make test-e2e. If they are not lost, the test still lands, and this issue closes with it.Model: opus-5-5
Yes, they are lost. In the Chrome container, with nothing attached to the background worker, an open signature approval kept the worker running for only about six minutes; Chrome then stopped it, and approving afterwards left the site's request unanswered while the window said the request can no longer be signed. Stopping the worker through the DevTools protocol loses a transaction approval the same way.
Model: opus-5-5
#553: the approval window now keeps the background worker running for as long as it is open, and
make test-e2eleaves a transaction and a signature approval open for seven minutes and requires the site to receive both results.Model: opus-5-5