-
Notifications
You must be signed in to change notification settings - Fork 422
Cut 0.2 #4254
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
Cut 0.2 #4254
Conversation
If we complete a `ChannelMonitorUpdate` persistence but there are
blocked `ChannelMonitorUpdate`s in the channel, we'll skip all the
post-monitor-update logic entirely. While its correct that we can't
resume the channel (as it expected the monitor updates it generated
to complete, even if they ended up blocked), the post-update
actions are a `channelmanager.rs` concept - they cannot be tied to
blocked updates because `channelmanager.rs` doesn't even see
blocked updates.
This can lead to a channel getting stuck waiting on itself. In a
production environment, an LDK user saw a case where:
(a) an MPP payment was received over several channels, let's call
them A + B.
(b) channel B got into `AwaitingRAA` due to unrelated operations,
(c) the MPP payment was claimed, with async monitor updating,
(d) the `revoke_and_ack` we were waiting on was delivered, but the
resulting `ChannelMonitorUpdate` was blocked due to the
pending claim having inserted an RAA-blocking action,
(e) the preimage `ChannelMonitorUpdate` generated for channel B
completed persistence, which did nothing due to the blocked
`ChannelMonitorUpdate`.
(f) the `Event::PaymentClaimed` event was handled but it, too,
failed to unblock the channel.
Instead, here, we simply process post-update actions when an update
completes, even if there are pending blocked updates. We do not
fully unblock the channel, of course.
Backport of 8f4a4d2
Conflicts due to upstream macro rewrite resolved in:
* lightning/src/ln/channelmanager.rs
This aligns `handle_monitor_update_completion` closer with upstream after backporting 8f4a4d2, making potential future backports somewhat simpler.
Various fields in `ChannelDetails` refer to channel information which changes on splice, which we ensure is consistently documented here. Backport of c3cc331
|
👋 Thanks for assigning @wpaulino as a reviewer! |
ae32294 to
d7ec833
Compare
|
Included the 0.1.8 changelog from #4255 since we should list the bug fixes there |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 0.2 #4254 +/- ##
==========================================
+ Coverage 88.86% 88.88% +0.02%
==========================================
Files 180 180
Lines 138042 138117 +75
Branches 138042 138117 +75
==========================================
+ Hits 122667 122772 +105
+ Misses 12557 12528 -29
+ Partials 2818 2817 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
d7ec833 to
e276b44
Compare
|
Oops, had to update the commit sha in the 0.1.8 changelog commit message after rebasing #4255, this should be good to go now. |
Backport of #4236 and #4250 then cut 0.2 🎉