Tweak pending_htlc_intercepts ser on manager read
What the developer wrote
Authored by Valentine Wallace
Tweak pending_htlc_intercepts ser on manager read
Makes an upcoming commit cleaner
What changed, and why it matters
This is a small internal code cleanup in the Lightning Dev Kit's channel manager. It changes how an in-memory data structure (tracking intercepted HTLCs) is initialized when reading persisted state, so that a future commit can be simpler. There is no indication this fixes a security bug or changes externally observable behavior.
No security action required; treat as routine refactor.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The commit refactors deserialization of pending_intercepted_htlcs_legacy in ChannelManager::read. Previously it was initialized to Some(new_hash_map()) and later unwrapped. Now it starts as None, is populated by the macro-generated deserialization, and is unwrapped-or-defaulted alongside similar legacy maps. The downstream .retain() call and final field assignment are updated to use the unwrapped map directly. This is a preparatory refactor with no functional change to serialization format or runtime behavior.
Changed components
lightning/src/ln/channelmanager.rsInspect captured patch +5 / −3
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index a48eaa4..a854bb7 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -17307,7 +17307,7 @@ where
// set from the `Channel{Monitor}`s instead, as a step towards removing the requirement of
// regularly persisting the `ChannelManager`.
let mut pending_intercepted_htlcs_legacy: Option<HashMap<InterceptId, PendingAddHTLCInfo>> =
- Some(new_hash_map());
+ None;
let mut decode_update_add_htlcs_legacy: Option<HashMap<u64, Vec<msgs::UpdateAddHTLC>>> =
None;
@@ -17356,6 +17356,8 @@ where
});
let mut decode_update_add_htlcs_legacy =
decode_update_add_htlcs_legacy.unwrap_or_else(|| new_hash_map());
+ let mut pending_intercepted_htlcs_legacy =
+ pending_intercepted_htlcs_legacy.unwrap_or_else(|| new_hash_map());
let peer_storage_dir: Vec<(PublicKey, Vec<u8>)> = peer_storage_dir.unwrap_or_else(Vec::new);
if fake_scid_rand_bytes.is_none() {
fake_scid_rand_bytes = Some(args.entropy_source.get_secure_random_bytes());
@@ -17746,7 +17748,7 @@ where
});
!forwards.is_empty()
});
- pending_intercepted_htlcs_legacy.as_mut().unwrap().retain(|intercepted_id, htlc_info| {
+ pending_intercepted_htlcs_legacy.retain(|intercepted_id, htlc_info| {
if pending_forward_matches_htlc(&htlc_info) {
log_info!(logger, "Removing pending intercepted HTLC with hash {} as it was forwarded to the closed channel {}",
&htlc.payment_hash, &monitor.channel_id());
@@ -18244,7 +18246,7 @@ where
inbound_payment_key: expanded_inbound_key,
pending_outbound_payments: pending_outbounds,
- pending_intercepted_htlcs: Mutex::new(pending_intercepted_htlcs_legacy.unwrap()),
+ pending_intercepted_htlcs: Mutex::new(pending_intercepted_htlcs_legacy),
forward_htlcs: Mutex::new(forward_htlcs_legacy),
decode_update_add_htlcs: Mutex::new(decode_update_add_htlcs_legacy),
Why this scored 12/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.