Be a bit more verbose in the `_actions_deferred` mon upd handler
What the developer wrote
Authored by Matt Corallo
Be a bit more verbose in the `_actions_deferred` mon upd handler
In 99df17e3654c37006aa2b630a4f8341669be845f we moved the "call
style" argument out of `handle_new_monitor_update`, making each an
individual macro instead. For the
`REMAIN_LOCKED_UPDATE_ACTIONS_PROCESSED_LATER` call style, we
renamed the macro `handle_new_monitor_update_actions_deferred`.
That name doesn't really capture the requirements of that
incredibly-awkward macro - namely that the actions need to be
processed by the caller (rather than just being "deferred" and
handled in some automated way later) and that the macro really
should only be used when the callsite needs the peer state locks to
remain locked, rather than being able to drop them to handle
post-update actions.
Here we rename it to the (mouthful)
`handle_new_monitor_update_locked_actions_handled_by_caller`.
Luckily its only used in two places.
What changed, and why it matters
This commit is a pure code cleanup: it renames an internal Rust macro to a longer, more descriptive name. No behavior, logic, or security properties change. It is not a security fix.
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 renames the macro handle_new_monitor_update_actions_deferred to handle_new_monitor_update_locked_actions_handled_by_caller in lightning/src/ln/channelmanager.rs. The macro’s body is unchanged, and both call sites are updated to use the new name. The change is purely cosmetic/documentation-oriented to clarify that the caller must process the resulting actions while peer-state locks remain held.
Changed components
lightning/src/ln/channelmanager.rsInspect captured patch +5 / −4
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 22efcee..73d98b2 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -3288,8 +3288,9 @@ macro_rules! locked_close_channel {
}};
($self: ident, $peer_state: expr, $funded_chan: expr, $shutdown_res_mut: expr, FUNDED) => {{
if let Some((_, funding_txo, _, update)) = $shutdown_res_mut.monitor_update.take() {
- handle_new_monitor_update_actions_deferred!($self, funding_txo, update, $peer_state,
- $funded_chan.context);
+ handle_new_monitor_update_locked_actions_handled_by_caller!(
+ $self, funding_txo, update, $peer_state, $funded_chan.context
+ );
}
// If there's a possibility that we need to generate further monitor updates for this
// channel, we need to store the last update_id of it. However, we don't want to insert
@@ -3741,7 +3742,7 @@ macro_rules! handle_post_close_monitor_update {
/// 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_actions_deferred {
+macro_rules! handle_new_monitor_update_locked_actions_handled_by_caller {
(
$self: ident, $funding_txo: expr, $update: expr, $peer_state: expr, $chan_context: expr
) => {{
@@ -14360,7 +14361,7 @@ where
insert_short_channel_id!(short_to_chan_info, funded_channel);
if let Some(monitor_update) = monitor_update_opt {
- handle_new_monitor_update_actions_deferred!(
+ handle_new_monitor_update_locked_actions_handled_by_caller!(
self,
funding_txo,
monitor_update,
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.