lnurlw callback called twice with same payment hash?

[JssDWt]

@tlindi had an issue with a combination of lnbits, bolt card and Breez. Lnbits and Breez show an error after scanning the bolt card with Breez. He sent me a screenshot in DM. The error comes from lnbits and is something like UNIQUE constraint failed apipayments.wallet, apipayments.checking_id

I checked, and the checking_id is the payment hash of the invoice that is supplied in the lnurlw callback. The unique constraint failing must be because the callback is invoked multiple times. Now, lnbits should display a better message there, saying 'invoice was already paid', or it should attempt to pay the invoice anyway if it wasn;t paid yet. That's out of scope for Breez.

But is it possible that Breez either creates an invoice with the same payment hash twice, or calls the callback multiple times with the same invoice?

[roeierez]

@tlindi Does it happen in POS mode when trying to receive payment for a sale? @JssDWt could you DM me the screenshot and logs from @tlindi device?

[roeierez]

The issue happens when trying to get a payment in POS mode using NFC card. In that case we already have an invoice generated for that amount and we use it in the callback of the lnurl widthdraw. In case the user scans more than once (might be not deliberately) the lnurl flow is activated and we send the same invoice to the callback URL resulting in this specific service error. We must send the same invoice in order not to risk in multiple payments from the payer but we can prevent the lnurl flow from running concurrently, skipping all LNUR requests as long as we have one in progress.

@ademar111190 what do you think?

[tlindi]

LNBits seems now have merged PR related to this at https://github.com/lnbits/lnbits/issues/1571