-
Notifications
You must be signed in to change notification settings - Fork 418
Remove direct calls to handle_monitor_update_completion!
#3947
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
Remove direct calls to handle_monitor_update_completion!
#3947
Conversation
👋 Thanks for assigning @tnull as a reviewer! |
Tagging 0.2 cause it technically fixes #3894 (comment) |
👋 The first review has been submitted! Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer. |
`handle_monitor_update_completion!` (and `handle_monitor_update_completion_actions`) are a pretty annoying API as they have several preconditions. Luckily, we already have `channel_monitor_update` which does the right work, handling both the open- and closed- channel cases and correctly checking the preconditions to `handle_monitor_update_completion!`, so here we convert calls to `handle_monitor_update_completion!` (aside from `handle_new_monitor_update!`) to just calling `channelMonitor_update`.
942cefc
to
8b9b078
Compare
$ git diff-tree -U7 -b 942cefcd47 8b9b078586
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 51247c173f..c47eaec623 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -8641,30 +8641,28 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
if let Some(highest_applied_update_id) = highest_applied_update_id {
pending.retain(|upd| upd.update_id > highest_applied_update_id);
log_trace!(
logger,
"ChannelMonitor updated to {highest_applied_update_id}. {} pending in-flight updates.",
pending.len()
);
- } else {
- if let Some(update) = pending.get(0) {
+ } else if let Some(update) = pending.get(0) {
log_trace!(
logger,
"ChannelMonitor updated to {}. {} pending in-flight updates.",
update.update_id - 1,
pending.len()
);
} else {
log_trace!(
logger,
"ChannelMonitor updated. {} pending in-flight updates.",
pending.len()
);
}
- }
pending.len()
} else { 0 };
if remaining_in_flight != 0 {
return;
} |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3947 +/- ##
==========================================
- Coverage 89.01% 89.00% -0.01%
==========================================
Files 168 168
Lines 121784 121822 +38
Branches 121784 121822 +38
==========================================
+ Hits 108411 108433 +22
- Misses 10966 10983 +17
+ Partials 2407 2406 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
handle_monitor_update_completion!
(andhandle_monitor_update_completion_actions
) are a pretty annoying API as they have several preconditions. Luckily, we already havechannel_monitor_update
which does the right work, handling both the open- and closed- channel cases and correctly checking the preconditions tohandle_monitor_update_completion!
, so here we convert calls tohandle_monitor_update_completion!
(aside fromhandle_new_monitor_update!
) to just callingchannelMonitor_update
.