-
Notifications
You must be signed in to change notification settings - Fork 421
[0.1] Handle mon update completion actions even with update(s) is blocked #4235
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
base: 0.1
Are you sure you want to change the base?
[0.1] Handle mon update completion actions even with update(s) is blocked #4235
Conversation
|
I've assigned @wpaulino as a reviewer! |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## 0.1 #4235 +/- ##
=======================================
Coverage 87.48% 87.49%
=======================================
Files 149 149
Lines 101834 101924 +90
Branches 101834 101924 +90
=======================================
+ Hits 89092 89180 +88
+ Misses 10479 10473 -6
- Partials 2263 2271 +8 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
0596cb2 to
23a3719
Compare
`Duration::new` adds any nanoseconds in excess of a second to the second part. This can overflow, however, panicking. In 0.2 we introduced a few further cases where we store `Duration`s, specifically some when handling network messages. Sadly, that introduced a remotely-triggerable crash where someone can send us, for example, a malicious blinded path context which can cause us to panic. Found by the `onion_message` fuzzer Backport of 7b9bde1
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.
XXX: Backport of XXX
Fixed conflicts in:
* lightning/src/ln/chanmon_update_fail_tests.rs
* lightning/src/ln/channelmanager.rs
* lightning/src/ln/functional_test_utils.rs
23a3719 to
bad3b46
Compare
bad3b46 to
35af975
Compare
35af975 to
52528c7
Compare
If we complete a
ChannelMonitorUpdatepersistence but there are blockedChannelMonitorUpdates 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 achannelmanager.rsconcept - they cannot be tied to blocked updates becausechannelmanager.rsdoesn'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
AwaitingRAAdue to unrelated operations,(c) the MPP payment was claimed, with async monitor updating,
(d) the
revoke_and_ackwe were waiting on was delivered, but theresulting
ChannelMonitorUpdatewas blocked due to thepending claim having inserted an RAA-blocking action,
(e) the preimage
ChannelMonitorUpdategenerated for channel Bcompleted persistence, which did nothing due to the blocked
ChannelMonitorUpdate.(f) the
Event::PaymentClaimedevent 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 #4236 (that needs to go first so I can update the commit hash), plus a backport of #4172.