Skip to content

[0.1] Handle mon update completion actions even with update(s) is blocked - #4235

Merged
TheBlueMatt merged 4 commits into
lightningdevkit:0.1from
TheBlueMatt:2025-11-post-update-even-when-blocked-0.1
Dec 2, 2025
Merged

[0.1] Handle mon update completion actions even with update(s) is blocked#4235
TheBlueMatt merged 4 commits into
lightningdevkit:0.1from
TheBlueMatt:2025-11-post-update-even-when-blocked-0.1

Conversation

@TheBlueMatt

@TheBlueMattTheBlueMatt commented Nov 20, 2025

Copy link
Copy Markdown
Collaborator

If we complete a ChannelMonitorUpdate persistence but there are blocked ChannelMonitorUpdates 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 #4236 (that needs to go first so I can update the commit hash), plus a backport of #4172.

@ldk-reviews-bot

ldk-reviews-bot commented Nov 20, 2025

Copy link
Copy Markdown

I've assigned @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@codecov

codecovBot commented Nov 20, 2025

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 93.12977% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.48%. Comparing base (4c1aa13) to head (21037ce).
⚠️ Report is 5 commits behind head on 0.1.

Files with missing linesPatch %Lines
lightning/src/ln/functional_test_utils.rs86.04%1 Missing and 5 partials ⚠️
lightning/src/ln/chanmon_update_fail_tests.rs97.50%2 Missing ⚠️
lightning/src/util/ser.rs66.66%1 Missing ⚠️
Additional details and impacted files
@@ Coverage Diff @@## 0.1 #4235 +/- ##
=======================================
Coverage 87.48% 87.48% =======================================
Files 149 149 Lines 101834 101924 +90 Branches 101834 101924 +90 =======================================
+ Hits 89092 89172 +80 - Misses 10479 10486 +7 - Partials 2263 2266 +3 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@TheBlueMatt
TheBlueMattforce-pushed the 2025-11-post-update-even-when-blocked-0.1 branch from 0596cb2 to 23a3719CompareNovember 20, 2025 14:07
`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
@TheBlueMatt
TheBlueMattforce-pushed the 2025-11-post-update-even-when-blocked-0.1 branch from 23a3719 to bad3b46CompareNovember 20, 2025 14:12
@TheBlueMatt
TheBlueMattforce-pushed the 2025-11-post-update-even-when-blocked-0.1 branch from bad3b46 to 35af975CompareNovember 20, 2025 14:33
@TheBlueMatt
TheBlueMattforce-pushed the 2025-11-post-update-even-when-blocked-0.1 branch from 35af975 to 52528c7CompareNovember 20, 2025 15:29
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
Fixed conflicts in:
* lightning/src/ln/chanmon_update_fail_tests.rs
* lightning/src/ln/channelmanager.rs
* lightning/src/ln/functional_test_utils.rs
@TheBlueMatt
TheBlueMattforce-pushed the 2025-11-post-update-even-when-blocked-0.1 branch from d8d4fee to 159a363CompareDecember 1, 2025 02:38
@TheBlueMatt
TheBlueMattforce-pushed the 2025-11-post-update-even-when-blocked-0.1 branch from 159a363 to 21037ceCompareDecember 1, 2025 02:44
@TheBlueMattTheBlueMatt mentioned this pull request Dec 2, 2025
@TheBlueMatt
TheBlueMatt merged commit b133293 into lightningdevkit:0.1Dec 2, 2025
22 of 26 checks passed
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@TheBlueMatt@ldk-reviews-bot@wpaulino