Handle mon update completion actions even with update(s) is blocked #4236
+271
−135
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.