ln: add channel monitor recovery for trampoline forwards
What the developer wrote
Authored by Maurice
ln: add channel monitor recovery for trampoline forwards
Implement channel monitor recovery for trampoline forwards
iterating over all hop data and updating pending forwards.
What changed, and why it matters
This commit fills in a previously unimplemented 'todo!' placeholder in the Lightning Dev Kit's channel recovery logic. When a node restarts and rebuilds its state from channel monitors, it now properly handles HTLCs (pending payments) that arrived as Trampoline forwards. Before this change, such forwards would have caused a panic during recovery, potentially preventing the node from restarting cleanly and possibly leaving forwarded payments stuck or lost.
Treat as a routine reliability/robustness fix. Review whether any test coverage exists for monitor-only recovery of trampoline forwards; if absent, add regression tests. No immediate security response appears necessary based solely on this diff.
Security signals we found
Replaced a todo!() panic stub in recovery path with proper state reconciliation
Trampoline forwards were not previously recoverable from channel monitors on restart
Missing recovery could leave pending HTLCs unprocessed after a crash/restart
Patch aligns TrampolineForward handling with existing Forward and OutboundRoute paths
Evidence from the diff
In channelmanager.rs, the HTLCSource::TrampolineForward arm of the monitor-based channel manager reconstruction logic was a todo!() stub. The patch replaces it with iteration over previous_hop_data and calls reconcile_pending_htlcs_with_monitor for each hop, mirroring the handling of non-trampoline forwards. This ensures pending trampoline forwards are re-added to the appropriate internal queues (already_forwarded_htlcs, forward_htlcs_legacy, pending_intercepted_htlcs_legacy, decode_update_add_htlcs, decode_update_add_htlcs_legacy) and events are reconstructed consistently with other HTLC sources.
Changed components
lightning/src/ln/channelmanager.rsChannel monitor recovery / channel manager reconstructionTrampoline payment forwardingInspect captured patch +17 / −1
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index f0aaac0..260a9d0 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -19380,7 +19380,23 @@ impl<
monitor.channel_id(),
);
},
- HTLCSource::TrampolineForward { .. } => todo!(),
+ HTLCSource::TrampolineForward { previous_hop_data, .. } => {
+ for prev_hop_data in previous_hop_data {
+ reconcile_pending_htlcs_with_monitor(
+ reconstruct_manager_from_monitors,
+ &mut already_forwarded_htlcs,
+ &mut forward_htlcs_legacy,
+ &mut pending_events_read,
+ &mut pending_intercepted_htlcs_legacy,
+ &mut decode_update_add_htlcs,
+ &mut decode_update_add_htlcs_legacy,
+ prev_hop_data,
+ &logger,
+ htlc.payment_hash,
+ monitor.channel_id(),
+ );
+ }
+ },
HTLCSource::OutboundRoute {
payment_id,
session_priv,
Why this scored 41/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.