Use consistent unwrap_or_else pattern for optional TLV fields
What the developer wrote
Authored by Joost Jager
Use consistent unwrap_or_else pattern for optional TLV fields
Initialize pending_claiming_payments and monitor_update_blocked_actions_per_peer
with None and resolve with unwrap_or_else, matching the pattern used for other
optional hash map fields like pending_intercepted_htlcs_legacy.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
What changed, and why it matters
This is a small internal code cleanup in the Lightning Dev Kit's channel manager. It changes how two optional data fields are initialized during deserialization so they follow the same safe pattern already used elsewhere. There is no indication this fixes a security vulnerability or changes observable behavior for users.
No security action required. Treat as normal code-quality/refactoring commit.
Security signals we found
Removal of `.unwrap()` calls on optional fields
Use of `unwrap_or_else` with default constructors for defensive defaulting
No change to wire format, serialization, or public API
Evidence from the diff
The commit makes two fields (pending_claiming_payments and monitor_update_blocked_actions_per_peer) start as None instead of pre-initialized empty containers during TLV deserialization, then uses unwrap_or_else to supply defaults after reading. This removes two .unwrap() calls and aligns the code with the existing pending_intercepted_htlcs_legacy pattern. It is a consistency/refactoring change with no functional security impact evident from the diff.
Changed components
lightning/src/ln/channelmanager.rs deserialization pathInspect captured patch +4 / −6
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 970ca05..2df6576 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -17398,9 +17398,9 @@ impl<'a, ES: EntropySource, SP: SignerProvider, L: Logger>
let mut probing_cookie_secret: Option<[u8; 32]> = None;
let mut claimable_htlc_purposes = None;
let mut claimable_htlc_onion_fields = None;
- let mut pending_claiming_payments = Some(new_hash_map());
+ let mut pending_claiming_payments = None;
let mut monitor_update_blocked_actions_per_peer: Option<Vec<(_, BTreeMap<_, Vec<_>>)>> =
- Some(Vec::new());
+ None;
let mut events_override = None;
let mut legacy_in_flight_monitor_updates: Option<
HashMap<(PublicKey, OutPoint), Vec<ChannelMonitorUpdate>>,
@@ -17494,12 +17494,10 @@ impl<'a, ES: EntropySource, SP: SignerProvider, L: Logger>
pending_intercepted_htlcs_legacy: pending_intercepted_htlcs_legacy
.unwrap_or_else(new_hash_map),
pending_outbound_payments,
- // unwrap safety: pending_claiming_payments is guaranteed to be `Some` after read_tlv_fields
- pending_claiming_payments: pending_claiming_payments.unwrap(),
+ pending_claiming_payments: pending_claiming_payments.unwrap_or_else(new_hash_map),
received_network_pubkey,
- // unwrap safety: monitor_update_blocked_actions_per_peer is guaranteed to be `Some` after read_tlv_fields
monitor_update_blocked_actions_per_peer: monitor_update_blocked_actions_per_peer
- .unwrap(),
+ .unwrap_or_else(Vec::new),
fake_scid_rand_bytes,
claimable_htlc_purposes,
probing_cookie_secret,
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.