Group legacy fields in ChannelManagerData to deduplicate comment
What the developer wrote
Authored by Joost Jager
Group legacy fields in ChannelManagerData to deduplicate comment
Reorder the struct fields to place all three `_legacy` fields together
at the end, allowing the explanatory comment to appear once instead of
being duplicated three times.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
What changed, and why it matters
This commit is a pure code cleanup: it rearranges three struct fields in the Lightning channel manager so that a single comment can explain all of them instead of repeating the same comment three times. No behavior changes, no security fixes, and no bug fixes are present.
No security action needed. Treat as normal refactoring.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The patch reorders fields in ChannelManagerData in lightning/src/ln/channelmanager.rs. It moves forward_htlcs_legacy, pending_intercepted_htlcs_legacy, and decode_update_add_htlcs_legacy to the end of the struct and replaces three identical comments with one shared comment. Field order in a Rust struct can affect memory layout, but this is an internal pub(super) struct and the change is purely cosmetic/organizational. No logic, types, visibility, or serialization code is modified.
Changed components
lightning/src/ln/channelmanager.rsInspect captured patch +6 / −12
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index bbede95..970ca05 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -17224,18 +17224,10 @@ pub(super) struct ChannelManagerData<SP: SignerProvider> {
best_block_height: u32,
best_block_hash: BlockHash,
channels: Vec<FundedChannel<SP>>,
- // Marked `_legacy` because in versions > 0.2 we are taking steps to remove the requirement of
- // regularly persisting the `ChannelManager` and instead rebuild the set of HTLC forwards from
- // `Channel{Monitor}` data. See [`ChannelManager::read`].
- forward_htlcs_legacy: HashMap<u64, Vec<HTLCForwardInfo>>,
claimable_htlcs_list: Vec<(PaymentHash, Vec<ClaimableHTLC>)>,
peer_init_features: Vec<(PublicKey, InitFeatures)>,
pending_events_read: VecDeque<(events::Event, Option<EventCompletionAction>)>,
highest_seen_timestamp: u32,
- // Marked `_legacy` because in versions > 0.2 we are taking steps to remove the requirement of
- // regularly persisting the `ChannelManager` and instead rebuild the set of HTLC forwards from
- // `Channel{Monitor}` data. See [`ChannelManager::read`].
- pending_intercepted_htlcs_legacy: HashMap<InterceptId, PendingAddHTLCInfo>,
pending_outbound_payments: HashMap<PaymentId, PendingOutboundPayment>,
pending_claiming_payments: HashMap<PaymentHash, ClaimingPayment>,
received_network_pubkey: Option<PublicKey>,
@@ -17245,14 +17237,16 @@ pub(super) struct ChannelManagerData<SP: SignerProvider> {
claimable_htlc_purposes: Option<Vec<events::PaymentPurpose>>,
probing_cookie_secret: Option<[u8; 32]>,
claimable_htlc_onion_fields: Option<Vec<Option<RecipientOnionFields>>>,
- // Marked `_legacy` because in versions > 0.2 we are taking steps to remove the requirement of
- // regularly persisting the `ChannelManager` and instead rebuild the set of HTLC forwards from
- // `Channel{Monitor}` data. See [`ChannelManager::read`].
- decode_update_add_htlcs_legacy: HashMap<u64, Vec<msgs::UpdateAddHTLC>>,
inbound_payment_id_secret: Option<[u8; 32]>,
in_flight_monitor_updates: Option<HashMap<(PublicKey, ChannelId), Vec<ChannelMonitorUpdate>>>,
peer_storage_dir: Option<Vec<(PublicKey, Vec<u8>)>>,
async_receive_offer_cache: AsyncReceiveOfferCache,
+ // Marked `_legacy` because in versions > 0.2 we are taking steps to remove the requirement of
+ // regularly persisting the `ChannelManager` and instead rebuild the set of HTLC forwards from
+ // `Channel{Monitor}` data.
+ forward_htlcs_legacy: HashMap<u64, Vec<HTLCForwardInfo>>,
+ pending_intercepted_htlcs_legacy: HashMap<InterceptId, PendingAddHTLCInfo>,
+ decode_update_add_htlcs_legacy: HashMap<u64, Vec<msgs::UpdateAddHTLC>>,
}
/// Arguments for deserializing [`ChannelManagerData`].
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.