diff options
| author | Adam Soltys <[email protected]> | 2026-09-10 21:58:29 -0700 |
|---|---|---|
| committer | Adam Soltys <[email protected]> | 2026-09-10 21:58:29 -0700 |
| commit | db5218ec83c1d84da5a2062e514b65132bcfe240 (patch) | |
| tree | 647594f758dda7badbaef66fe95651532a7e631f /src/features/zaps.js | |
| parent | d654e2d1cb76aa4d1032db2c424b7937e44b9429 (diff) | |
| download | coinosv3-db5218ec83c1d84da5a2062e514b65132bcfe240.tar.gz coinosv3-db5218ec83c1d84da5a2062e514b65132bcfe240.zip | |
A zap of 21 showed 42 the moment it landed.
The optimistic amount is supposed to stand down when the real receipt is
counted, and it did — but only by deleting itself. An ark zap publishes its
own receipt, which comes back over the live subscription BEFORE the send
call resolves, so the flow's success report arrived second and re-created
the amount on top of the receipt already in the total. 21 paid, 42 shown.
The pending entry now has a state (flying / paid / void) instead of a
deletion: our receipt voids it, and a settle arriving afterwards can't
resurrect it. A receipt older than the tap — the backlog the first paint
fetches for a message zapped before — doesn't void anything, so zapping the
same message twice still counts both.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_019mrt228Upn9nNCwGixzSLx
Diffstat (limited to 'src/features/zaps.js')
0 files changed, 0 insertions, 0 deletions
