Consume vectors in monitor_updating_paused
What the developer wrote
Authored by Joost Jager
Consume vectors in monitor_updating_paused
Using extend is slightly cleaner because it doesn't require mut on the
parameters.
What changed, and why it matters
This is a minor internal code cleanup in the Lightning Dev Kit's channel handling. It changes how a function accepts several lists of pending actions, switching from mutable references that append into internal storage to a style that consumes the vectors directly. There is no user-visible behavior change 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 refactors monitor_updating_paused in lightning/src/ln/channel.rs. Previously the function took mut parameters and used Vec::append to move their contents into self.context fields. The patch removes the mut qualifiers and uses Vec::extend, which consumes the owned vectors and appends their elements. This is an idiomatic Rust cleanup with identical runtime semantics for the caller because the vectors were already owned values passed by value.
Changed components
lightning/src/ln/channel.rsChannel::monitor_updating_pausedInspect captured patch +6 / −9
diff --git a/lightning/src/ln/channel.rs b/lightning/src/ln/channel.rs
index 51475e1..f2775b6 100644
--- a/lightning/src/ln/channel.rs
+++ b/lightning/src/ln/channel.rs
@@ -9392,10 +9392,9 @@ where
/// [`ChannelMonitorUpdateStatus::InProgress`]: crate::chain::ChannelMonitorUpdateStatus::InProgress
fn monitor_updating_paused<L: Deref>(
&mut self, resend_raa: bool, resend_commitment: bool, resend_channel_ready: bool,
- mut pending_forwards: Vec<(PendingHTLCInfo, u64)>,
- mut pending_fails: Vec<(HTLCSource, PaymentHash, HTLCFailReason)>,
- mut pending_finalized_claimed_htlcs: Vec<(HTLCSource, Option<AttributionData>)>,
- logger: &L,
+ pending_forwards: Vec<(PendingHTLCInfo, u64)>,
+ pending_fails: Vec<(HTLCSource, PaymentHash, HTLCFailReason)>,
+ pending_finalized_claimed_htlcs: Vec<(HTLCSource, Option<AttributionData>)>, logger: &L,
) where
L::Target: Logger,
{
@@ -9404,11 +9403,9 @@ where
self.context.monitor_pending_revoke_and_ack |= resend_raa;
self.context.monitor_pending_commitment_signed |= resend_commitment;
self.context.monitor_pending_channel_ready |= resend_channel_ready;
- self.context.monitor_pending_forwards.append(&mut pending_forwards);
- self.context.monitor_pending_failures.append(&mut pending_fails);
- self.context
- .monitor_pending_finalized_fulfills
- .append(&mut pending_finalized_claimed_htlcs);
+ self.context.monitor_pending_forwards.extend(pending_forwards);
+ self.context.monitor_pending_failures.extend(pending_fails);
+ self.context.monitor_pending_finalized_fulfills.extend(pending_finalized_claimed_htlcs);
self.context.channel_state.set_monitor_update_in_progress();
}
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.