mirror of
https://github.com/minibits-cash/minibits_wallet.git
synced 2026-10-05 11:18:24 +00:00
minibits-cashandClaude Opus 5.5
57e8291278
A melt whose request and follow-up quote check both failed (mint unreachable) left its reservation open but unowned: inputs stayed locked until the next app restart and the user saw "Lightning payment failed". The reservation is now held and handed to the interrupted-operation resolver right away. It retries on each performChecks until the mint answers, then rolls back (tx REVERTED) or hands over to refresh. The user is told the payment status is unknown and the ecash is locked until it is confirmed. TransferOperationApi.prepare now refuses a transfer while another attempt for the same melt quote or invoice (payment hash) is PENDING, EXECUTING, or held by the resolver. The screen's Pay button re-uses the same quote after a failure. A mint settles a quote once, so this could not pay twice, but after the mint rejects the second melt, _handleExecuteError reads the shared quote state and would settle the second attempt's never-spent inputs as SPENT. The check runs before the draft is created and clears once the earlier attempt is resolved. Sentry noise: the "handing to resolver" logs and the resolver's per-sweep retry log are now warn. The thrown MintError (the AppError constructor logs it) and the failing mint call already report each incident once. Verified on the simulator: network cut mid-melt, retry refused, resolved to REVERTED with the balance restored once back online. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>