`unified_qr`: Consider continuing `receive` flow on offer creation failure

[tnull]

Currently, we error out UnifiedQrPayment::receive if we fail to create an offer. However, this could happen if we don't have suitable channels for blinded path creation. While it's not entirely clear what behavior is preferable, we should at least consider just continuing receive so that the user can always fall back to the onchain bip21 part.

[Anyitechs]

Hi @tnull, I'll like to work on this but I want to ensure I understand this correctly.

By continuing the receive flow, do you mean:

• Taking off the return statement from return Err(Error::OfferCreationFailed); and return Err(Error::InvoiceCreationFailed); on bolt12_offer and bolt11_invoice respectively and just propagate the error variant to the variable? Or,
• Not to worry about the offer and invoice creation failure (maybe only log the error but do not block the flow) and continue the receive flow?

Either way, do you think continuing the flow on offer/invoice creation failure won't affect the behaviour some wallets might expect from the BIP21 [URI] following this comment below on the UnifiedQrPayment::receive?

The URI allows users to send the payment request allowing the wallet to decide which payment method to use. This enables a fallback mechanism: older wallets can always pay using the provided on-chain address, while newer wallets will typically opt to use the provided BOLT11 invoice or BOLT12 offer.

[tnull]

By continuing the receive flow, do you mean:

Hi! I meant the latter, i.e., continuing the flow. Essentially this issue is really here to remind me to think about it once more if we really should. The change itself should be ~only dropping the return statement.

Either way, do you think continuing the flow on offer/invoice creation failure won't affect the behaviour some wallets might expect from the BIP21 [URI] following this comment below on the UnifiedQrPayment::receive?

Well, it would mostly result in a BIP21 that will only hold a BOLT11 invoice, and worst-case will be on-chain only. It's a bit weird to have that degradation on the receive side, which is why I'm not fully sure yet if we should or if it's preferable to explicitly tell the user that we weren't able to create the full thing.

[Anyitechs]

Well, it would mostly result in a BIP21 that will only hold a BOLT11 invoice, and worst-case will be on-chain only. It's a bit weird to have that degradation on the receive side, which is why I'm not fully sure yet if we should or if it's preferable to explicitly tell the user that we weren't able to create the full thing.

I agree. The degradation might not make sense, but if we eventually do that, then we should be communicating that so users are aware of it.

[Camillarhi]

Hi @tnull , revisiting this after encountering Err(Error::OfferCreationFailed) and Err(Error::InvoiceCreationFailed) in practice. @Anyitechs had previously suggested logging the error but not blocking the flow.

Is there consensus on the preferred approach (degrading gracefully vs. explicit errors)?

I’d be happy to collaborate with @Anyitechs on a patch, or help test/prototype solutions
Just want to align with the intended resolution before jumping in. Thanks!

[tnull]

Is there consensus on the preferred approach (degrading gracefully vs. explicit errors)?

I guess we could degrade gracefully and just log if we omit the BOLT12 part. Feel free to provide a patch for it!

[Camillarhi]

Is there consensus on the preferred approach (degrading gracefully vs. explicit errors)?

I guess we could degrade gracefully and just log if we omit the BOLT12 part. Feel free to provide a patch for it!

Thanks! I'll prepare a patch with the graceful fallback and logging.