Skip to content

Commit 037a1d7

Browse files
committed
Properly provide PaymentPathSuccessful event for replay claims
When a payment was sent and ultimately completed through an on-chain HTLC claim which we discover during startup, we deliberately break the payment tracking logic to keep it around forever, declining to send a `PaymentPathSuccessful` event but ensuring that we don't constantly replay the claim on every startup. However, now that we now have logic to complete a claim by marking it as completed in a `ChannelMonitor` and not replaying information about the claim on every startup. Thus, we no longer need to take the conservative stance and can correctly replay claims now, generating `PaymentPathSuccessful` events and allowing the state to be removed.
1 parent 500fc91 commit 037a1d7

File tree

3 files changed

+23
-18
lines changed

3 files changed

+23
-18
lines changed

lightning/src/ln/channelmanager.rs

Lines changed: 1 addition & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -16565,21 +16565,13 @@ where
1656516565
let mut compl_action = Some(
1656616566
EventCompletionAction::ReleasePaymentCompleteChannelMonitorUpdate(update)
1656716567
);
16568-
// Note that we set `from_onchain` to "false" here,
16569-
// deliberately keeping the pending payment around forever.
16570-
// Given it should only occur when we have a channel we're
16571-
// force-closing for being stale that's okay.
16572-
// The alternative would be to wipe the state when claiming,
16573-
// generating a `PaymentPathSuccessful` event but regenerating
16574-
// it and the `PaymentSent` on every restart until the
16575-
// `ChannelMonitor` is removed.
1657616568
pending_outbounds.claim_htlc(
1657716569
payment_id,
1657816570
preimage,
1657916571
bolt12_invoice,
1658016572
session_priv,
1658116573
path,
16582-
false,
16574+
true,
1658316575
&mut compl_action,
1658416576
&pending_events,
1658516577
&&logger,

lightning/src/ln/monitor_tests.rs

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3359,12 +3359,15 @@ fn do_test_lost_preimage_monitor_events(on_counterparty_tx: bool) {
33593359

33603360
check_added_monitors(&nodes[1], 0);
33613361
let preimage_events = nodes[1].node.get_and_clear_pending_events();
3362-
assert_eq!(preimage_events.len(), 2, "{preimage_events:?}");
3362+
assert_eq!(preimage_events.len(), 3, "{preimage_events:?}");
33633363
for ev in preimage_events {
33643364
match ev {
33653365
Event::PaymentSent { payment_hash, .. } => {
33663366
assert_eq!(payment_hash, hash_b);
33673367
},
3368+
Event::PaymentPathSuccessful { payment_hash, .. } => {
3369+
assert_eq!(payment_hash, Some(hash_b));
3370+
},
33683371
Event::PaymentForwarded { claim_from_onchain_tx, .. } => {
33693372
assert!(claim_from_onchain_tx);
33703373
},

lightning/src/ln/payment_tests.rs

Lines changed: 18 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1379,13 +1379,19 @@ fn do_test_dup_htlc_onchain_doesnt_fail_on_reload(
13791379
} else {
13801380
expect_payment_sent(&nodes[0], payment_preimage, None, true, false);
13811381
}
1382-
// After reload, the ChannelManager identified the failed payment and queued up the
1383-
// PaymentSent (or not, if `persist_manager_post_event` resulted in us detecting we
1384-
// already did that) and corresponding ChannelMonitorUpdate to mark the payment
1385-
// handled, but while processing the pending `MonitorEvent`s (which were not processed
1386-
// before the monitor was persisted) we will end up with a duplicate
1387-
// ChannelMonitorUpdate.
1388-
check_added_monitors(&nodes[0], 2);
1382+
if persist_manager_post_event {
1383+
// After reload, the ChannelManager identified the failed payment and queued up the
1384+
// PaymentSent (or not, if `persist_manager_post_event` resulted in us detecting we
1385+
// already did that) and corresponding ChannelMonitorUpdate to mark the payment
1386+
// handled, but while processing the pending `MonitorEvent`s (which were not processed
1387+
// before the monitor was persisted) we will end up with a duplicate
1388+
// ChannelMonitorUpdate.
1389+
check_added_monitors(&nodes[0], 2);
1390+
} else {
1391+
// ...unless we got the PaymentSent event, in which case we have de-duplication logic
1392+
// preventing a redundant monitor event.
1393+
check_added_monitors(&nodes[0], 1);
1394+
}
13891395
}
13901396

13911397
// Note that if we re-connect the block which exposed nodes[0] to the payment preimage (but
@@ -4130,7 +4136,7 @@ fn do_no_missing_sent_on_reload(persist_manager_with_payment: bool, at_midpoint:
41304136
// pending payment from being re-hydrated on the next startup.
41314137
let events = nodes[0].node.get_and_clear_pending_events();
41324138
check_added_monitors(&nodes[0], 1);
4133-
assert_eq!(events.len(), 2);
4139+
assert_eq!(events.len(), 3, "{events:?}");
41344140
if let Event::ChannelClosed { reason: ClosureReason::OutdatedChannelManager, .. } = events[0] {
41354141
} else {
41364142
panic!();
@@ -4140,6 +4146,10 @@ fn do_no_missing_sent_on_reload(persist_manager_with_payment: bool, at_midpoint:
41404146
} else {
41414147
panic!();
41424148
}
4149+
if let Event::PaymentPathSuccessful { .. } = events[2] {
4150+
} else {
4151+
panic!();
4152+
}
41434153
// Note that we don't get a PaymentPathSuccessful here as we leave the HTLC pending to avoid
41444154
// the double-claim that would otherwise appear at the end of this test.
41454155
nodes[0].node.timer_tick_occurred();

0 commit comments

Comments
 (0)