Skip to content

Commit c0ab9e3

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 00ae67d commit c0ab9e3

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
@@ -16715,21 +16715,13 @@ where
1671516715
let mut compl_action = Some(
1671616716
EventCompletionAction::ReleasePaymentCompleteChannelMonitorUpdate(update)
1671716717
);
16718-
// Note that we set `from_onchain` to "false" here,
16719-
// deliberately keeping the pending payment around forever.
16720-
// Given it should only occur when we have a channel we're
16721-
// force-closing for being stale that's okay.
16722-
// The alternative would be to wipe the state when claiming,
16723-
// generating a `PaymentPathSuccessful` event but regenerating
16724-
// it and the `PaymentSent` on every restart until the
16725-
// `ChannelMonitor` is removed.
1672616718
pending_outbounds.claim_htlc(
1672716719
payment_id,
1672816720
preimage,
1672916721
bolt12_invoice,
1673016722
session_priv,
1673116723
path,
16732-
false,
16724+
true,
1673316725
&mut compl_action,
1673416726
&pending_events,
1673516727
&&logger,

lightning/src/ln/monitor_tests.rs

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

34513451
check_added_monitors(&nodes[1], 0);
34523452
let preimage_events = nodes[1].node.get_and_clear_pending_events();
3453-
assert_eq!(preimage_events.len(), 2, "{preimage_events:?}");
3453+
assert_eq!(preimage_events.len(), 3, "{preimage_events:?}");
34543454
for ev in preimage_events {
34553455
match ev {
34563456
Event::PaymentSent { payment_hash, .. } => {
34573457
assert_eq!(payment_hash, hash_b);
34583458
},
3459+
Event::PaymentPathSuccessful { payment_hash, .. } => {
3460+
assert_eq!(payment_hash, Some(hash_b));
3461+
},
34593462
Event::PaymentForwarded { claim_from_onchain_tx, .. } => {
34603463
assert!(claim_from_onchain_tx);
34613464
},

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)