Remove handle_new_monitor_update_locked_actions_handled_by_caller macro
What changed, and why it matters
This commit is a straightforward code cleanup: it removes an internal Rust macro and replaces its two uses with direct calls to the underlying function. There is no indication of a bug fix, behavior change, or security issue.
No security action needed; treat as routine refactoring.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The commit deletes the handle_new_monitor_update_locked_actions_handled_by_caller macro in lightning/src/ln/channelmanager.rs and inlines the equivalent self.update_channel_monitor(...) call at its two former call sites. The macro previously wrapped update_channel_monitor and returned only update_completed; the inlined calls now discard the return value implicitly. The commit message is purely refactor-oriented and generated by Claude Code. No security relevance is stated or evident from the diff.
Changed components
lightning/src/ln/channelmanager.rsInspect captured patch +8 / −33
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 1747bdf..26a45e5 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -3338,31 +3338,6 @@ macro_rules! handle_post_close_monitor_update {
update_completed
}};
}
-
-/// Handles a new monitor update without dropping peer_state locks and calling
-/// [`ChannelManager::handle_monitor_update_completion_actions`] if the monitor update completed
-/// synchronously.
-///
-/// Useful because monitor updates need to be handled in the same mutex where the channel generated
-/// them (otherwise they can end up getting applied out-of-order) but it's not always possible to
-/// drop the aforementioned peer state locks at a given callsite. In this situation, use this macro
-/// to apply the monitor update immediately and handle the monitor update completion actions at a
-/// later time.
-macro_rules! handle_new_monitor_update_locked_actions_handled_by_caller {
- (
- $self: ident, $funding_txo: expr, $update: expr, $in_flight_monitor_updates: expr, $chan_context: expr
- ) => {{
- let (update_completed, _all_updates_complete) = $self.update_channel_monitor(
- $in_flight_monitor_updates,
- $chan_context.channel_id(),
- $funding_txo,
- $chan_context.get_counterparty_node_id(),
- $update,
- );
- update_completed
- }};
-}
-
macro_rules! handle_new_monitor_update {
(
$self: ident, $funding_txo: expr, $update: expr, $peer_state_lock: expr, $peer_state: expr,
@@ -4546,12 +4521,12 @@ where
log_error!(logger, "Closed channel due to close-required error: {}", msg);
if let Some((_, funding_txo, _, update)) = shutdown_res.monitor_update.take() {
- handle_new_monitor_update_locked_actions_handled_by_caller!(
- self,
+ self.update_channel_monitor(
+ in_flight_monitor_updates,
+ chan.context.channel_id(),
funding_txo,
+ chan.context.get_counterparty_node_id(),
update,
- in_flight_monitor_updates,
- chan.context
);
}
// If there's a possibility that we need to generate further monitor updates for this
@@ -14853,12 +14828,12 @@ where
insert_short_channel_id!(short_to_chan_info, funded_channel);
if let Some(monitor_update) = monitor_update_opt {
- handle_new_monitor_update_locked_actions_handled_by_caller!(
- self,
+ self.update_channel_monitor(
+ &mut peer_state.in_flight_monitor_updates,
+ funded_channel.context.channel_id(),
funding_txo,
+ funded_channel.context.get_counterparty_node_id(),
monitor_update,
- &mut peer_state.in_flight_monitor_updates,
- funded_channel.context
);
to_process_monitor_update_actions.push((
counterparty_node_id, channel_id
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.