OffersMessageHandler may handle an InvoiceError in response to either an InvoiceRequest or Bolt12Invoice sent via the onion message reply path. It may also send an InvoiceError in such scenarios. Currently, however, it doesn't update OutboundPayments (when applicable) or generate any Events, when appropriate.
Different scenarios must be considered:
- sending vs receiving the
InvoiceError
- whether the
InvoiceError is in response to an InvoiceRequest or Bolt12Invoice
- whether the
InvoiceError corresponds to an Offer or Refund
Implementing the correct behavior may involve providing additional information in the reply path such that the received InvoiceError can be correlated with a payment.
For example, when receiving an InvoiceError in response to an InvoiceRequest, OutboundPayments should be updated and generate an Event::InvoiceRequestFailed. However, this requires knowing the PaymentId when handling the InvoiceError. To implement this properly, the reply path must not only contain this data, but the handler interface must change to provide this information.
There may also be a case where we send a Bolt12Invoice without a reply path, so there won't be an InvoiceError response. Fixing this, if needed, would require further changes to the handler interface to allow for adding a reply path.
OffersMessageHandlermay handle anInvoiceErrorin response to either anInvoiceRequestorBolt12Invoicesent via the onion message reply path. It may also send anInvoiceErrorin such scenarios. Currently, however, it doesn't updateOutboundPayments(when applicable) or generate anyEvents, when appropriate.Different scenarios must be considered:
InvoiceErrorInvoiceErroris in response to anInvoiceRequestorBolt12InvoiceInvoiceErrorcorresponds to anOfferorRefundImplementing the correct behavior may involve providing additional information in the reply path such that the received
InvoiceErrorcan be correlated with a payment.For example, when receiving an
InvoiceErrorin response to anInvoiceRequest,OutboundPaymentsshould be updated and generate anEvent::InvoiceRequestFailed. However, this requires knowing thePaymentIdwhen handling theInvoiceError. To implement this properly, the reply path must not only contain this data, but the handler interface must change to provide this information.There may also be a case where we send a
Bolt12Invoicewithout a reply path, so there won't be anInvoiceErrorresponse. Fixing this, if needed, would require further changes to the handler interface to allow for adding a reply path.