Fix BOLT11 DuplicatePayment triggering on-chain fallback in unified payment - #1038
Fix BOLT11 DuplicatePayment triggering on-chain fallback in unified payment#1038elnafateh wants to merge 2 commits into
Conversation
|
👋 Thanks for assigning @ajaysehwal as a reviewer! |
…ayments Error::DuplicatePayment is now terminal in UnifiedPayment::send, preventing a duplicate Lightning payment from falling back to an on-chain payment.
d2e30c9 to
981bc8a
Compare
There was a problem hiding this comment.
@elnafateh, the BOLT11 fix looks good. DuplicatePayment is now treated as terminal, while other BOLT11 failures still fall back to on-chain as intended.
One adjacent issue is still present in the BOLT12 path: all errors, including DuplicatePayment, still fall through to BOLT11. That said, BOLT12 has a slightly different retry risk because it generates a fresh random PaymentId for each payment. So a retry is unlikely to hit DuplicatePayment; instead, it could successfully start another BOLT12 payment or fall through to BOLT11/on-chain and potentially double-pay.
I don't think this is introduced by this PR, but it may be worth tracking separately.
There was a problem hiding this comment.
Thanks @ajaysehwal, glad the BOLT11 fix looks good. Agreed on BOLT12 — I'm tracking it as a separate follow up issue/PR and leaving this one scoped to #1033
3 participants
UnifiedPayment::sendpreviously fell back to the on-chain method after anyBOLT11 error, including
Error::DuplicatePayment. Retrying a unified BIP21payment could pay the recipient twice — once over Lightning, once on-chain.
Error::DuplicatePaymentis now treated as terminal and returned to thecaller immediately, preventing the unsafe fallback.
Adds an integration test covering the retry scenario.
#1033