Skip to content

Conversation

@TheBlueMatt
Copy link
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.

@TheBlueMatt TheBlueMatt added this to the 0.2 milestone Nov 20, 2025
@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Nov 20, 2025

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
Copy link

codecov bot commented Nov 20, 2025

Codecov Report

❌ Patch coverage is 94.82759% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.33%. Comparing base (6d9c676) to head (eb5492f).

Files with missing lines Patch % Lines
lightning/src/ln/functional_test_utils.rs 84.61% 1 Missing and 5 partials ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##             main    #4236   +/-   ##
=======================================
  Coverage   89.32%   89.33%           
=======================================
  Files         180      180           
  Lines      138641   138714   +73     
  Branches   138641   138714   +73     
=======================================
+ Hits       123844   123922   +78     
+ Misses      12174    12167    -7     
- Partials     2623     2625    +2     
Flag Coverage Δ
fuzzing 35.96% <2.32%> (-0.01%) ⬇️
tests 88.70% <94.82%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ 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 TheBlueMatt force-pushed the 2025-11-post-update-even-when-blocked branch from d28804e to 6700e7c Compare November 20, 2025 13:53
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants