aboutsummaryrefslogtreecommitdiffstats
path: root/src/nwc-lock.js
Commit message (Collapse)AuthorAgeFilesLines
* A closed wallet's NWC payments fit iOS's ten-second wake: a paid send is ↵Adam Soltys10 days1-3/+10
| | | | | | | | | | | | | | | never marked for revocation by a second wake, lookups report outgoing sends and finish them, and pushes no longer run side by side PullCap's night of 2026-10-24: every wake's diary stopped 8-12 s after its push (iOS stops the worker there, not at 30 s). Two wakes two seconds apart both drove one send; the second's InitiateLightningPayment was refused ("state: ln-spent") and the paid send went to 'revoking', where every later wake spent its whole budget on it, so no request was answered after midnight. - manager: an initiate refused as ln-spent follows the payment ('initiated'); a send in 'revoking' asks the ASP first (paid: settle; in flight before expiry: back to waiting; not found: revoke) - worker: 9 s budget on Apple endpoints (27 s elsewhere) for answers, earlier sends and renewals; every ASP step held to it - lookup_invoice asks every copy of the connection and drives an outgoing send in flight, answering settled with the preimage - a lease in the worker's IndexedDB store serialises pushes (the Web Lock didn't); diary notes a missing Web Locks API - the reply and the mirror save run together; stuck sends are finished before a new payment only when they hold its coins Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QjVvE4YAcK3AGwV7kZXeN4
* A closed wallet finishes the Lightning sends an earlier wake left in flight, ↵Adam Soltys11 days1-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | instead of calling the invoice "already paid" with no preimage and locking its coin until the app opens PullCap's night of 2026-10-23 (hourly 1-sat NWC requests to a closed iPhone PWA): three of fifteen hours went wrong the same way. The push woke the worker, it reserved the coin and wrote the ln-pay action to the mirror, and the phone stopped it before the ASP was ever asked (no cosign in captaind's log for those minutes). The client's retry ten minutes later hit the manager's duplicate check, "this invoice was already paid or is being paid", published as an INTERNAL error that the client read as paid — hours before the money moved. And since the stuck action held the wallet's only coin, the next hour's request (a different invoice) found nothing spendable and fell to "Open Coinos to approve". Everything settled at once when the app opened at 07:12 and resumed the actions. - nwc-respond.js: pay_invoice first looks for a send already on the books for this invoice — finishing one in flight and answering with its preimage, repeating the preimage of one already done (nothing new on the spend log) — and before paying a new invoice drives any other stuck send to completion so its coin comes back. tendLnPays() does the same on every wake, lookups included, and hands back "Payment sent" lines for what settled. rec.pendingPays remembers which connection a send belongs to (the action is the manager's); the app's mirror rewrite carries it. - manager.js: the duplicate check says "already paid" only for a settled send, "already in progress" for one on its way. - features/nwc.js: the open app answers a repeated invoice from the local action (preimage when settled, an honest "still in progress" otherwise) before asking the ASP about a sibling device. - sw-nwc.js: one push at a time over the shared mirror (Web Lock), so a client's lookup + retry seconds apart can't double-drive one send. A diary of what the worker did — each push, each ln-pay step as the mirror saves it, every notification shown or refused, the fallback taken — is appended line by line to IndexedDB (nwc-bg.js appendBgLog), so a worker the phone stops mid-push leaves its last step behind. Settings → Notifications → "Background activity log" copies it. - tests: nwc-sw-test covers the four resumed-send cases; sw-push-quota mocks the new seams and its "suspended app" case now expects the stand-in-first order shipped in 91dbee4 (it had been failing since). Co-Authored-By: Claude Fable 5.1 <[email protected]>
* A zap answered by two tabs no longer reports as failed.Adam Soltys2026-09-141-0/+14
Every open tab of the same wallet sees every wallet-connect request. Two hidden tabs on one laptop both tried to pay the same zap: the ASP refused the second with "payment already in progress", and that error reached Amethyst half a second before the first tab's preimage. A Web Lock per request now lets one tab (or the worker) answer while the rest stay quiet, and a device that does meet "already in progress" waits for the sibling payment's outcome — relaying its preimage only if the payer never speaks — instead of shouting a failure over sats that went through. The losing side also stops writing a failed row into history for it. Co-Authored-By: Claude Fable 5.1 <[email protected]> Claude-Session: https://claude.ai/code/session_01QYJfZ4A1TDCEY4Foq3CApR