-
Notifications
You must be signed in to change notification settings - Fork 364
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
Don't pay a duplicate BOLT 12 invoice if ChannelManager
is stale
#3313
Don't pay a duplicate BOLT 12 invoice if ChannelManager
is stale
#3313
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3313 +/- ##
==========================================
- Coverage 89.65% 89.62% -0.03%
==========================================
Files 126 126
Lines 102546 102622 +76
Branches 102546 102622 +76
==========================================
+ Hits 91935 91975 +40
- Misses 7890 7924 +34
- Partials 2721 2723 +2 ☔ View full report in Codecov by Sentry. |
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
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.
Thanks, yea, I think this looks right, though it'd be nice to include a test that sent the payment MPP.
19dc035
to
cd5709f
Compare
Adapted the test to use MPP, as a fixup in case you meant a separate test. |
Move the code that ensures that HTLCs locked into ChannelMonitors are synchronized with the ChannelManager's OutboundPayments store to the outbound_payments module. This is useful both because ChannelManager::read is very long/confusing method, so it's nice to encapsulate some of its functionality, and because we need to fix an existing bug in this logic where we may risk double-paying an offer due to outbound_payments being stale on startup. See the next commit for this bugfix.
cd5709f
to
0c2c339
Compare
Rebased due to silent conflict. |
LGTM, feel free to squash IMO. |
2f1542e
to
ffe936b
Compare
Squashed. |
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 modulo any CI failures. Can't tell from the UI.
This fixes the following bug: - An outbound payment is AwaitingInvoice - We receive an invoice and lock the HTLCs into the relevant ChannelMonitors - The monitors are successfully persisted, but the ChannelManager fails to persist, so the outbound payment remains AwaitingInvoice - We restart, causing the channels to close due to a stale ChannelManager - We receive a duplicate invoice, and attempt to pay it again due to the payment still being AwaitingInvoice in the stale ChannelManager After the fix for this, we will notice that the payment is already locked into the monitor on startup and transition the incorrectly-AwaitingInvoice payment to Retryable, which prevents double-paying on duplicate invoice receipt.
ffe936b
to
fbb3ab2
Compare
Kicked CI 🤞 |
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 but the test needs to make sure we actually get PaymentSent
events, which is the other half of not double-paying, but can happen in a followup.
// attempt would have resulted in a PaymentFailed event here, since the only channels between | ||
// Alice and Bob is closed. Since no 2nd attempt should be made, check that no events are | ||
// generated in response to the duplicate invoice. | ||
assert!(nodes[0].node.get_and_clear_pending_events().is_empty()); |
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.
We should follow through, claiming the HTLCs on-chain and making sure we get a PaymentSent
event.
Caught by @TheBlueMatt: #3140 (comment).