Trivial: ChannelManager::read var rename prefactor
What the developer wrote
Authored by Valentine Wallace
Trivial: ChannelManager::read var rename prefactor
Makes an upcoming commit cleaner: when we add a next_hop variable we want to
distinguish it from the previous hop.
What changed, and why it matters
This is a purely cosmetic code cleanup. It renames local variables in the ChannelManager deserialization code from 'hop_data' to 'prev_hop' and 'is_channel_closed' to 'is_downstream_closed' to make a future change easier to read. No logic, behavior, or security properties change.
No action needed; this is a non-functional refactor.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The commit performs identifier renaming only within channelmanager.rs. The tuple destructuring ‘for (payment_hash, hop_data, outbound_amt_msat)’ becomes ‘for (payment_hash, prev_hop, outbound_amt_msat)’, and all downstream uses of that binding are updated. A local boolean ‘is_channel_closed’ is renamed ‘is_downstream_closed’. The types, control flow, and values are unchanged. The commit message explicitly states this is a trivial prefactor for an upcoming change.
Changed components
lightning/src/ln/channelmanager.rsInspect captured patch +8 / −8
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 68eeb7c..cc95424 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -18637,13 +18637,13 @@ impl<
.or_insert_with(Vec::new)
.push(update_add_htlc);
}
- for (payment_hash, hop_data, outbound_amt_msat) in
+ for (payment_hash, prev_hop, outbound_amt_msat) in
funded_chan.inbound_forwarded_htlcs()
{
already_forwarded_htlcs
- .entry((hop_data.channel_id, payment_hash))
+ .entry((prev_hop.channel_id, payment_hash))
.or_insert_with(Vec::new)
- .push((hop_data, outbound_amt_msat));
+ .push((prev_hop, outbound_amt_msat));
}
}
}
@@ -19352,14 +19352,14 @@ impl<
if let Some(forwarded_htlcs) =
already_forwarded_htlcs.remove(&(*channel_id, payment_hash))
{
- for (hop_data, outbound_amt_msat) in forwarded_htlcs {
+ for (prev_hop, outbound_amt_msat) in forwarded_htlcs {
let new_pending_claim =
!pending_claims_to_replay.iter().any(|(src, _, _, _, _, _, _)| {
- matches!(src, HTLCSource::PreviousHopData(hop) if hop.htlc_id == hop_data.htlc_id && hop.channel_id == hop_data.channel_id)
+ matches!(src, HTLCSource::PreviousHopData(hop) if hop.htlc_id == prev_hop.htlc_id && hop.channel_id == prev_hop.channel_id)
});
if new_pending_claim {
let counterparty_node_id = monitor.get_counterparty_node_id();
- let is_channel_closed = channel_manager
+ let is_downstream_closed = channel_manager
.per_peer_state
.read()
.unwrap()
@@ -19372,10 +19372,10 @@ impl<
.contains_key(channel_id)
});
pending_claims_to_replay.push((
- HTLCSource::PreviousHopData(hop_data),
+ HTLCSource::PreviousHopData(prev_hop),
payment_preimage,
outbound_amt_msat,
- is_channel_closed,
+ is_downstream_closed,
counterparty_node_id,
monitor.get_funding_txo(),
*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.