-
Notifications
You must be signed in to change notification settings - Fork 365
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a separate PaymentSendFailure for idempotency violation #1826
Add a separate PaymentSendFailure for idempotency violation #1826
Conversation
e86760f
to
34a6c1a
Compare
Codecov 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
5fa0a6b
Compare
Rebased after dependent PR merge. |
5fa0a6b
to
207374a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise LGTM I think
CI sad |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
fcf73f0
Compare
Squashed without further change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No - "not yet completed or been abandoned" has the opposite meaning from "not yet completed or has been abandoned" :).
PathParameterError(Vec<Result<(), APIError>>), | ||
/// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// paths than the ones selected). | |
/// paths than the ones previously selected). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
PaymentSendFailure
enum variant forDuplicatePayment
to allow for that.