I have a lightning application that initiates payments using xpay over gRPC.
How can I reliably figure out the status of the payment.
The problem with listpays
The problem is that lispays can transiently report "failed" while cln is still actively trying the payment. The status oscilates between "pending" and "failed" between individual route attempts.
We observed the issue on a lightning node and I created a repro which yields the following results.
pending (x44) -> failed (x8) -> pending (x50) -> failed (x8) -> pending (x42) -> failed (x7) -> ... -> complete
A user who falsely believes that a payment has failed can run into danger.
- Eg: user tries another delivery method if lightning fails and end up paying twice
- Eg: when implementing swaps the user might revoke the incoming asset because the payment has failed
The problem with waiting for a gRPC response
The xpay command returns once the payment is completed.
However, there is no guarantuee that we actually receive the response in case of network issues.
What should I do if this happens?
I don't want to call listpays because the payment might be marked as failed and end up succeeding.
I have a lightning application that initiates payments using
xpayover gRPC.How can I reliably figure out the status of the payment.
The problem with
listpaysThe problem is that
lispayscan transiently report"failed"while cln is still actively trying the payment. The status oscilates between"pending"and"failed"between individual route attempts.We observed the issue on a lightning node and I created a repro which yields the following results.
A user who falsely believes that a payment has failed can run into danger.
The problem with waiting for a gRPC response
The
xpaycommand returns once the payment is completed.However, there is no guarantuee that we actually receive the response in case of network issues.
What should I do if this happens?
I don't want to call
listpaysbecause the payment might be marked as failed and end up succeeding.