ln/refactor: add previous_hop_data helper for HTLCSource
What changed, and why it matters
This commit is a straightforward internal code cleanup in the Lightning Dev Kit's channel manager. It extracts a small, repeated pattern for reading previous-hop routing data into a shared helper method. There is no change to behavior, no fix for a bug, and no security relevance visible in the diff or commit message.
No action needed. This is a non-security refactor.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The patch adds a previous_hop_data() method on HTLCSource and replaces two inline match blocks that did the same thing with calls to that helper. The helper returns a slice of HTLCPreviousHopData references. The logic is identical before and after: PreviousHopData yields a single-element slice, TrampolineForward yields its previous_hop_data slice, and OutboundRoute yields an empty slice. This is a pure refactor with no functional or security change.
Changed components
lightning/src/ln/channelmanager.rsInspect captured patch +14 / −19
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 3bd90db..7dd9d84 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -843,6 +843,14 @@ mod fuzzy_channelmanager {
},
}
}
+
+ pub(crate) fn previous_hop_data(&self) -> &[HTLCPreviousHopData] {
+ match self {
+ HTLCSource::PreviousHopData(prev_hop) => core::slice::from_ref(prev_hop),
+ HTLCSource::TrampolineForward { previous_hop_data, .. } => &previous_hop_data[..],
+ HTLCSource::OutboundRoute { .. } => &[],
+ }
+ }
}
/// Tracks the inbound corresponding to an outbound HTLC
@@ -12532,15 +12540,8 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
chan.update_fulfill_htlc(&msg),
chan_entry
);
- let prev_hops = match &res.0 {
- HTLCSource::PreviousHopData(prev_hop) => vec![prev_hop],
- HTLCSource::TrampolineForward { previous_hop_data, .. } => {
- previous_hop_data.iter().collect()
- },
- _ => vec![],
- };
let logger = WithChannelContext::from(&self.logger, &chan.context, None);
- for prev_hop in prev_hops {
+ for prev_hop in res.0.previous_hop_data() {
log_trace!(logger,
"Holding the next revoke_and_ack until the preimage is durably persisted in the inbound edge's ChannelMonitor",
);
@@ -19709,17 +19710,11 @@ impl<
.into_iter()
.filter_map(|(htlc_source, (htlc, preimage_opt))| {
let payment_preimage = preimage_opt?;
- let prev_htlcs = match &htlc_source {
- HTLCSource::PreviousHopData(prev_hop) => vec![prev_hop],
- HTLCSource::TrampolineForward { previous_hop_data, .. } => {
- previous_hop_data.iter().collect()
- },
- // If it was an outbound payment, we've handled it above - if a preimage
- // came in and we persisted the `ChannelManager` we either handled it
- // and are good to go or the channel force-closed - we don't have to
- // handle the channel still live case here.
- _ => vec![],
- };
+ // If it was an outbound payment, we've handled it above - if a preimage
+ // came in and we persisted the `ChannelManager` we either handled it
+ // and are good to go or the channel force-closed - we don't have to
+ // handle the channel still live case here.
+ let prev_htlcs = htlc_source.previous_hop_data();
let prev_htlcs_count = prev_htlcs.len();
if prev_htlcs_count == 0 {
return None;
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.