Extract macro for initial monitor persist
What changed, and why it matters
This commit is a small internal code cleanup in the Lightning Dev Kit's Rust implementation. It pulls out a repeated block of code into a new macro named handle_initial_monitor and updates the existing macro accordingly. There is no change to what the code actually does, no bug fix, and no security-relevant behavior change.
No action needed. This is a non-security refactoring commit.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The change refactors channelmanager.rs by extracting the INITIAL_MONITOR arm of the handle_new_monitor_update! macro into a separate handle_initial_monitor! macro. The extracted logic (calling handle_monitor_update_res, checking update_completed, and logging an error if incomplete) is unchanged. Call sites are updated to use the new macro. This is purely a readability/maintainability refactor with no functional or security impact.
Changed components
lightning/src/ln/channelmanager.rsInspect captured patch +10 / −7
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 83bba01..6b3bd5c 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -3658,8 +3658,8 @@ fn handle_monitor_update_res<CM: AChannelManager, LG: Logger>(
}
}
-macro_rules! handle_new_monitor_update {
- ($self: ident, $update_res: expr, $peer_state_lock: expr, $peer_state: expr, $per_peer_state_lock: expr, $chan: expr, INITIAL_MONITOR) => {
+macro_rules! handle_initial_monitor {
+ ($self: ident, $update_res: expr, $peer_state_lock: expr, $peer_state: expr, $per_peer_state_lock: expr, $chan: expr) => {
let logger = WithChannelContext::from(&$self.logger, &$chan.context, None);
let update_completed =
handle_monitor_update_res($self, $update_res, $chan.context.channel_id(), logger);
@@ -3673,6 +3673,9 @@ macro_rules! handle_new_monitor_update {
);
}
};
+}
+
+macro_rules! handle_new_monitor_update {
(
$self: ident, $funding_txo: expr, $update: expr, $peer_state: expr, $logger: expr,
$chan_id: expr, $counterparty_node_id: expr, $in_flight_updates: ident, $update_idx: ident,
@@ -10115,8 +10118,8 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
}
if let Some(funded_chan) = e.insert(Channel::from(chan)).as_funded_mut() {
- handle_new_monitor_update!(self, persist_state, peer_state_lock, peer_state,
- per_peer_state, funded_chan, INITIAL_MONITOR);
+ handle_initial_monitor!(self, persist_state, peer_state_lock, peer_state,
+ per_peer_state, funded_chan);
} else {
unreachable!("This must be a funded channel as we just inserted it.");
}
@@ -10279,7 +10282,7 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
})
{
Ok((funded_chan, persist_status)) => {
- handle_new_monitor_update!(self, persist_status, peer_state_lock, peer_state, per_peer_state, funded_chan, INITIAL_MONITOR);
+ handle_initial_monitor!(self, persist_status, peer_state_lock, peer_state, per_peer_state, funded_chan);
Ok(())
},
Err(e) => try_channel_entry!(self, peer_state, Err(e), chan_entry),
@@ -10904,8 +10907,8 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
if let Some(monitor) = monitor_opt {
let monitor_res = self.chain_monitor.watch_channel(monitor.channel_id(), monitor);
if let Ok(persist_state) = monitor_res {
- handle_new_monitor_update!(self, persist_state, peer_state_lock, peer_state,
- per_peer_state, chan, INITIAL_MONITOR);
+ handle_initial_monitor!(self, persist_state, peer_state_lock, peer_state,
+ per_peer_state, chan);
} else {
let logger = WithChannelContext::from(&self.logger, &chan.context, None);
log_error!(logger, "Persisting initial ChannelMonitor failed, implying the channel ID was duplicated");
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.