-
Notifications
You must be signed in to change notification settings - Fork 417
Ensure partial MPP claims continue to blocks channels on restart #3928
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: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -8274,25 +8274,44 @@ where | |
// payment claim from a `ChannelMonitor`. In some cases (MPP or | ||
// if the HTLC was only recently removed) we make such claims | ||
// after an HTLC has been removed from a channel entirely, and | ||
// thus the RAA blocker has long since completed. | ||
// thus the RAA blocker may have long since completed. | ||
// | ||
// In any other case, the RAA blocker must still be present and | ||
// blocking RAAs. | ||
debug_assert!( | ||
during_init | ||
|| peer_state | ||
.actions_blocking_raa_monitor_updates | ||
.get(&chan_id) | ||
.unwrap() | ||
.contains(&raa_blocker) | ||
); | ||
// However, its possible that the `ChannelMonitorUpdate` containing | ||
// the preimage never completed and is still pending. In that case, | ||
// we need to re-add the RAA blocker, which we do here. Handling | ||
// the post-update action, below, will remove it again. | ||
// | ||
// In any other case (i.e. not during startup), the RAA blocker | ||
// must still be present and blocking RAAs. | ||
let actions = &mut peer_state.actions_blocking_raa_monitor_updates; | ||
let actions_list = actions.entry(chan_id).or_insert_with(Vec::new); | ||
if !actions_list.contains(&raa_blocker) { | ||
debug_assert!(during_init); | ||
actions_list.push(raa_blocker); | ||
} | ||
} | ||
let action = if let Some(action) = action_opt { | ||
action | ||
} else { | ||
return; | ||
}; | ||
|
||
// If there are monitor updates in flight, we may be in the case | ||
// described above, replaying a claim on startup which needs an RAA | ||
// blocker to remain blocked. Thus, in such a case we simply push the | ||
// post-update action to the blocked list and move on. | ||
Comment on lines
+8299
to
+8302
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Based on an existing test, it seems like we can also hit this case when There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, if I put an There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm talking about adding an assert here: diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index b60b0419a..8b7f89119 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -8302,6 +8302,7 @@ where
// post-update action to the blocked list and move on.
let in_flight_mons = peer_state.in_flight_monitor_updates.get(&chan_id);
if in_flight_mons.map(|(_, mons)| !mons.is_empty()).unwrap_or(false) {
+ assert!(during_init);
peer_state
.monitor_update_blocked_actions
.entry(chan_id) So the case where we have (1) a duplicate claim, (2) in-flight monitor updates present and (3) a post-update action whilst There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I went ahead and tweaked the comment, but it shouldn't matter too much $ git diff-tree -U1 c15c1ecbd6 55eea49cd0
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index b60b0419a2..229d594d06 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -8302,2 +8302,4 @@ where
// post-update action to the blocked list and move on.
+ // In any case, we should air on the side of caution and not process
+ // the post-update action no matter the situation.
let in_flight_mons = peer_state.in_flight_monitor_updates.get(&chan_id); |
||
// In any case, we should air on the side of caution and not process | ||
// the post-update action no matter the situation. | ||
let in_flight_mons = peer_state.in_flight_monitor_updates.get(&chan_id); | ||
if in_flight_mons.map(|(_, mons)| !mons.is_empty()).unwrap_or(false) { | ||
peer_state | ||
.monitor_update_blocked_actions | ||
.entry(chan_id) | ||
.or_insert_with(Vec::new) | ||
.push(action); | ||
return; | ||
} | ||
|
||
mem::drop(peer_state_opt); | ||
|
||
log_trace!(logger, "Completing monitor update completion action for channel {} as claim was redundant: {:?}", | ||
|
Uh oh!
There was an error while loading. Please reload this page.