Move `handle_new_monitor_update_internal` above macros that use it
What changed, and why it matters
This commit simply moves a block of code earlier in the same file. It is a pure code reorganization with no functional changes, no bug fixes, and no security relevance.
No action required; this is a non-functional refactor.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The commit relocates the handle_new_monitor_update_internal macro definition above other macros that invoke it. The diff shows identical macro body content (53 lines removed and 53 lines added) with only line position changed. No logic, signatures, or behavior were modified.
Changed components
lightning/src/ln/channelmanager.rsInspect captured patch +53 / −53
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index fa1df90..67d3c3c 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -3696,6 +3696,59 @@ macro_rules! handle_initial_monitor {
};
}
+macro_rules! handle_new_monitor_update_internal {
+ (
+ $self: ident, $funding_txo: expr, $update: expr, $peer_state: expr, $logger: expr,
+ $chan_id: expr, $counterparty_node_id: expr, $all_completed: expr
+ ) => {{
+ let in_flight_updates = &mut $peer_state
+ .in_flight_monitor_updates
+ .entry($chan_id)
+ .or_insert_with(|| ($funding_txo, Vec::new()))
+ .1;
+ // During startup, we push monitor updates as background events through to here in
+ // order to replay updates that were in-flight when we shut down. Thus, we have to
+ // filter for uniqueness here.
+ let update_idx =
+ in_flight_updates.iter().position(|upd| upd == &$update).unwrap_or_else(|| {
+ in_flight_updates.push($update);
+ in_flight_updates.len() - 1
+ });
+ if $self.background_events_processed_since_startup.load(Ordering::Acquire) {
+ let update_res =
+ $self.chain_monitor.update_channel($chan_id, &in_flight_updates[update_idx]);
+ let update_completed = handle_monitor_update_res($self, update_res, $chan_id, $logger);
+ if update_completed {
+ let _ = in_flight_updates.remove(update_idx);
+ if in_flight_updates.is_empty() {
+ $all_completed;
+ }
+ }
+ update_completed
+ } else {
+ // We blindly assume that the ChannelMonitorUpdate will be regenerated on startup if we
+ // fail to persist it. This is a fairly safe assumption, however, since anything we do
+ // during the startup sequence should be replayed exactly if we immediately crash.
+ let event = BackgroundEvent::MonitorUpdateRegeneratedOnStartup {
+ counterparty_node_id: $counterparty_node_id,
+ funding_txo: $funding_txo,
+ channel_id: $chan_id,
+ update: in_flight_updates[update_idx].clone(),
+ };
+ // We want to track the in-flight update both in `in_flight_monitor_updates` and in
+ // `pending_background_events` to avoid a race condition during
+ // `pending_background_events` processing where we complete one
+ // `ChannelMonitorUpdate` (but there are more pending as background events) but we
+ // conclude that all pending `ChannelMonitorUpdate`s have completed and its safe to
+ // run post-completion actions.
+ // We could work around that with some effort, but its simpler to just track updates
+ // twice.
+ $self.pending_background_events.lock().unwrap().push(event);
+ false
+ }
+ }};
+}
+
macro_rules! handle_post_close_monitor_update {
(
$self: ident, $funding_txo: expr, $update: expr, $peer_state_lock: expr, $peer_state: expr,
@@ -3755,59 +3808,6 @@ macro_rules! handle_new_monitor_update_locked_actions_handled_by_caller {
}};
}
-macro_rules! handle_new_monitor_update_internal {
- (
- $self: ident, $funding_txo: expr, $update: expr, $peer_state: expr, $logger: expr,
- $chan_id: expr, $counterparty_node_id: expr, $all_completed: expr
- ) => {{
- let in_flight_updates = &mut $peer_state
- .in_flight_monitor_updates
- .entry($chan_id)
- .or_insert_with(|| ($funding_txo, Vec::new()))
- .1;
- // During startup, we push monitor updates as background events through to here in
- // order to replay updates that were in-flight when we shut down. Thus, we have to
- // filter for uniqueness here.
- let update_idx =
- in_flight_updates.iter().position(|upd| upd == &$update).unwrap_or_else(|| {
- in_flight_updates.push($update);
- in_flight_updates.len() - 1
- });
- if $self.background_events_processed_since_startup.load(Ordering::Acquire) {
- let update_res =
- $self.chain_monitor.update_channel($chan_id, &in_flight_updates[update_idx]);
- let update_completed = handle_monitor_update_res($self, update_res, $chan_id, $logger);
- if update_completed {
- let _ = in_flight_updates.remove(update_idx);
- if in_flight_updates.is_empty() {
- $all_completed;
- }
- }
- update_completed
- } else {
- // We blindly assume that the ChannelMonitorUpdate will be regenerated on startup if we
- // fail to persist it. This is a fairly safe assumption, however, since anything we do
- // during the startup sequence should be replayed exactly if we immediately crash.
- let event = BackgroundEvent::MonitorUpdateRegeneratedOnStartup {
- counterparty_node_id: $counterparty_node_id,
- funding_txo: $funding_txo,
- channel_id: $chan_id,
- update: in_flight_updates[update_idx].clone(),
- };
- // We want to track the in-flight update both in `in_flight_monitor_updates` and in
- // `pending_background_events` to avoid a race condition during
- // `pending_background_events` processing where we complete one
- // `ChannelMonitorUpdate` (but there are more pending as background events) but we
- // conclude that all pending `ChannelMonitorUpdate`s have completed and its safe to
- // run post-completion actions.
- // We could work around that with some effort, but its simpler to just track updates
- // twice.
- $self.pending_background_events.lock().unwrap().push(event);
- false
- }
- }};
-}
-
macro_rules! handle_new_monitor_update {
(
$self: ident, $funding_txo: expr, $update: expr, $peer_state_lock: expr, $peer_state: expr,
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.