Uh oh!
There was an error while loading. Please reload this page.
Add a separate PaymentSendFailure for idempotency violation - #1826
Conversation
e86760f to
34a6c1aCompareCodecov ReportBase: 90.79% // Head: 91.27% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@## main #1826 +/- ##
==========================================
+ Coverage 90.79% 91.27% +0.47%
==========================================
Files 87 87 Lines 47600 51304 +3704 Branches 47600 51304 +3704 ==========================================
+ Hits 43218 46826 +3608 - Misses 4382 4478 +96
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
4d46352 to
5fa0a6bCompareTheBlueMatt
commented
Nov 3, 2022
Rebased after dependent PR merge. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
5fa0a6b to
207374aCompare
valentinewallace
left a comment
There was a problem hiding this comment.
Otherwise LGTM I think
Uh oh!
There was an error while loading. Please reload this page.
valentinewallace
commented
Nov 8, 2022
CI sad |
valentinewallace
left a comment
There was a problem hiding this comment.
LGTM after squash
It was pointed out that its quite confusing that `AllFailedRetrySafe` does not allow you to call `retry_payment`, though the documentation on it does specify this. Instead, we simply rename it to `AllFailedResendSafe` to indicate that the action that is safe to take is *resending*, not *retrying*.
When a user attempts to send a payment but it fails due to idempotency key violation, they need to know that this was the reason as they need to handle the error programmatically differently from other errors. Here we simply add a new `PaymentSendFailure` enum variant for `DuplicatePayment` to allow for that.
c7c134c to
fcf73f0CompareTheBlueMatt
commented
Nov 9, 2022
Squashed without further change. |
tnull
left a comment
There was a problem hiding this comment.
LGTM.
Two tiny doc nits, but feel free to merge as is.
| /// for this payment. | ||
| AllFailedResendSafe(Vec<APIError>), | ||
| /// Indicates that a payment for the provided [`PaymentId`] is already in-flight and has not | ||
| /// yet completed (i.e. generated an [`Event::PaymentSent`]) or been abandoned (via |
There was a problem hiding this comment.
| /// yet completed (i.e. generated an [`Event::PaymentSent`]) or been abandoned (via | |
| /// yet completed (i.e. generated an [`Event::PaymentSent`]) or has been abandoned (via |
There was a problem hiding this comment.
No - "not yet completed or been abandoned" has the opposite meaning from "not yet completed or has been abandoned" :).
| /// All paths which were attempted failed to send, with no channel state change taking place. | ||
| /// You can freely retry the payment in full (though you probably want to do so over different | ||
| /// You can freely resend the payment in full (though you probably want to do so over different | ||
| /// paths than the ones selected). |
There was a problem hiding this comment.
| /// paths than the ones selected). | |
| /// paths than the ones previously selected). |
There was a problem hiding this comment.
Would rather replace selected with attempted, but not sure its worth it - I don't think anyone is gonna be confused here.
Built on #1761, admittedly this should have gone into #1761 but that's done now and I was thinking I really wanted to overhaul the error types entirely, which I'm not sure is really true now.
When a user attempts to send a payment but it fails due to
idempotency key violation, they need to know that this was the
reason as they need to handle the error programmatically
differently from other errors.
Here we simply add a new
PaymentSendFailureenum variant forDuplicatePaymentto allow for that.