Skip to content

Commit d6f805c

Browse files
Remove retry_payments method
We're no longer supporting manual retries since ChannelManager::send_payment_with_retry can be parameterized by a retry strategy This commit also updates all docs related to retry_payment and abandon_payment. Since these docs frequently overlap with changes in preceding commits where we start abandoning payments on behalf of the user, all the docs are updated in one go.
1 parent 3859b4c commit d6f805c

File tree

5 files changed

+64
-156
lines changed

5 files changed

+64
-156
lines changed

lightning/src/ln/channelmanager.rs

+14-33
Original file line numberDiff line numberDiff line change
@@ -1175,9 +1175,9 @@ pub enum RecentPaymentDetails {
11751175
/// made before LDK version 0.0.104.
11761176
payment_hash: Option<PaymentHash>,
11771177
},
1178-
/// After a payment is explicitly abandoned by calling [`ChannelManager::abandon_payment`], it
1179-
/// is marked as abandoned until an [`Event::PaymentFailed`] is generated. A payment could also
1180-
/// be marked as abandoned if pathfinding fails repeatedly or retries have been exhausted.
1178+
/// After a payment's retries are exhausted per the provided [`Retry`], or it is explicitly
1179+
/// abandoned via [`ChannelManager::abandon_payment`], it is marked as abandoned until an
1180+
/// [`Event::PaymentFailed`] is generated.
11811181
Abandoned {
11821182
/// Hash of the payment that we have given up trying to send.
11831183
payment_hash: PaymentHash,
@@ -1726,7 +1726,7 @@ where
17261726
///
17271727
/// This can be useful for payments that may have been prepared, but ultimately not sent, as a
17281728
/// result of a crash. If such a payment exists, is not listed here, and an
1729-
/// [`Event::PaymentSent`] has not been received, you may consider retrying the payment.
1729+
/// [`Event::PaymentSent`] has not been received, you may consider resending the payment.
17301730
///
17311731
/// [`Event::PaymentSent`]: events::Event::PaymentSent
17321732
pub fn list_recent_payments(&self) -> Vec<RecentPaymentDetails> {
@@ -2484,8 +2484,8 @@ where
24842484
/// If a pending payment is currently in-flight with the same [`PaymentId`] provided, this
24852485
/// method will error with an [`APIError::InvalidRoute`]. Note, however, that once a payment
24862486
/// is no longer pending (either via [`ChannelManager::abandon_payment`], or handling of an
2487-
/// [`Event::PaymentSent`]) LDK will not stop you from sending a second payment with the same
2488-
/// [`PaymentId`].
2487+
/// [`Event::PaymentSent`] or [`Event::PaymentFailed`]) LDK will not stop you from sending a
2488+
/// second payment with the same [`PaymentId`].
24892489
///
24902490
/// Thus, in order to ensure duplicate payments are not sent, you should implement your own
24912491
/// tracking of payments, including state to indicate once a payment has completed. Because you
@@ -2530,6 +2530,7 @@ where
25302530
/// [`Route`], we assume the invoice had the basic_mpp feature set.
25312531
///
25322532
/// [`Event::PaymentSent`]: events::Event::PaymentSent
2533+
/// [`Event::PaymentFailed`]: events::Event::PaymentFailed
25332534
/// [`PeerManager::process_events`]: crate::ln::peer_handler::PeerManager::process_events
25342535
/// [`ChannelMonitorUpdateStatus::InProgress`]: crate::chain::ChannelMonitorUpdateStatus::InProgress
25352536
pub fn send_payment(&self, route: &Route, payment_hash: PaymentHash, payment_secret: &Option<PaymentSecret>, payment_id: PaymentId) -> Result<(), PaymentSendFailure> {
@@ -2567,41 +2568,21 @@ where
25672568
}
25682569

25692570

2570-
/// Retries a payment along the given [`Route`].
2571-
///
2572-
/// Errors returned are a superset of those returned from [`send_payment`], so see
2573-
/// [`send_payment`] documentation for more details on errors. This method will also error if the
2574-
/// retry amount puts the payment more than 10% over the payment's total amount, if the payment
2575-
/// for the given `payment_id` cannot be found (likely due to timeout or success), or if
2576-
/// further retries have been disabled with [`abandon_payment`].
2577-
///
2578-
/// [`send_payment`]: [`ChannelManager::send_payment`]
2579-
/// [`abandon_payment`]: [`ChannelManager::abandon_payment`]
2580-
pub fn retry_payment(&self, route: &Route, payment_id: PaymentId) -> Result<(), PaymentSendFailure> {
2581-
let best_block_height = self.best_block.read().unwrap().height();
2582-
self.pending_outbound_payments.retry_payment_with_route(route, payment_id, &self.entropy_source, &self.node_signer, best_block_height,
2583-
|path, payment_params, payment_hash, payment_secret, total_value, cur_height, payment_id, keysend_preimage, session_priv|
2584-
self.send_payment_along_path(path, payment_params, payment_hash, payment_secret, total_value, cur_height, payment_id, keysend_preimage, session_priv))
2585-
}
2586-
2587-
/// Signals that no further retries for the given payment will occur.
2571+
/// Signals that no further retries for the given payment should occur. Useful if you have a
2572+
/// pending outbound payment with retries remaining, but wish to cancel it before retries are
2573+
/// exhausted.
25882574
///
2589-
/// After this method returns, no future calls to [`retry_payment`] for the given `payment_id`
2590-
/// are allowed. If no [`Event::PaymentFailed`] event had been generated before, one will be
2591-
/// generated as soon as there are no remaining pending HTLCs for this payment.
2575+
/// If no [`Event::PaymentFailed`] event had been generated before, one will be generated as soon
2576+
/// as there are no remaining pending HTLCs for this payment.
25922577
///
25932578
/// Note that calling this method does *not* prevent a payment from succeeding. You must still
25942579
/// wait until you receive either a [`Event::PaymentFailed`] or [`Event::PaymentSent`] event to
25952580
/// determine the ultimate status of a payment.
25962581
///
25972582
/// If an [`Event::PaymentFailed`] event is generated and we restart without this
2598-
/// [`ChannelManager`] having been persisted, the payment may still be in the pending state
2599-
/// upon restart. This allows further calls to [`retry_payment`] (and requiring a second call
2600-
/// to [`abandon_payment`] to mark the payment as failed again). Otherwise, future calls to
2601-
/// [`retry_payment`] will fail with [`PaymentSendFailure::ParameterError`].
2583+
/// [`ChannelManager`] having been persisted, another [`Event::PaymentFailed`] event may be
2584+
/// generated.
26022585
///
2603-
/// [`abandon_payment`]: Self::abandon_payment
2604-
/// [`retry_payment`]: Self::retry_payment
26052586
/// [`Event::PaymentFailed`]: events::Event::PaymentFailed
26062587
/// [`Event::PaymentSent`]: events::Event::PaymentSent
26072588
pub fn abandon_payment(&self, payment_id: PaymentId) {

lightning/src/ln/outbound_payment.rs

+23-33
Original file line numberDiff line numberDiff line change
@@ -323,68 +323,58 @@ pub enum PaymentSendFailure {
323323
///
324324
/// You can freely resend the payment in full (with the parameter error fixed).
325325
///
326-
/// Because the payment failed outright, no payment tracking is done, you do not need to call
327-
/// [`ChannelManager::abandon_payment`] and [`ChannelManager::retry_payment`] will *not* work
328-
/// for this payment.
326+
/// Because the payment failed outright, no payment tracking is done and no
327+
/// [`Event::PaymentPathFailed`] or [`Event::PaymentFailed`] events will be generated.
329328
///
330-
/// [`ChannelManager::abandon_payment`]: crate::ln::channelmanager::ChannelManager::abandon_payment
331-
/// [`ChannelManager::retry_payment`]: crate::ln::channelmanager::ChannelManager::retry_payment
329+
/// [`Event::PaymentPathFailed`]: crate::util::events::Event::PaymentPathFailed
330+
/// [`Event::PaymentFailed`]: crate::util::events::Event::PaymentFailed
332331
ParameterError(APIError),
333332
/// A parameter in a single path which was passed to send_payment was invalid, preventing us
334333
/// from attempting to send the payment at all.
335334
///
336335
/// You can freely resend the payment in full (with the parameter error fixed).
337336
///
337+
/// Because the payment failed outright, no payment tracking is done and no
338+
/// [`Event::PaymentPathFailed`] or [`Event::PaymentFailed`] events will be generated.
339+
///
338340
/// The results here are ordered the same as the paths in the route object which was passed to
339341
/// send_payment.
340342
///
341-
/// Because the payment failed outright, no payment tracking is done, you do not need to call
342-
/// [`ChannelManager::abandon_payment`] and [`ChannelManager::retry_payment`] will *not* work
343-
/// for this payment.
344-
///
345-
/// [`ChannelManager::abandon_payment`]: crate::ln::channelmanager::ChannelManager::abandon_payment
346-
/// [`ChannelManager::retry_payment`]: crate::ln::channelmanager::ChannelManager::retry_payment
343+
/// [`Event::PaymentPathFailed`]: crate::util::events::Event::PaymentPathFailed
344+
/// [`Event::PaymentFailed`]: crate::util::events::Event::PaymentFailed
347345
PathParameterError(Vec<Result<(), APIError>>),
348346
/// All paths which were attempted failed to send, with no channel state change taking place.
349347
/// You can freely resend the payment in full (though you probably want to do so over different
350348
/// paths than the ones selected).
351349
///
352-
/// Because the payment failed outright, no payment tracking is done, you do not need to call
353-
/// [`ChannelManager::abandon_payment`] and [`ChannelManager::retry_payment`] will *not* work
354-
/// for this payment.
350+
/// Because the payment failed outright, no payment tracking is done and no
351+
/// [`Event::PaymentPathFailed`] or [`Event::PaymentFailed`] events will be generated.
355352
///
356-
/// [`ChannelManager::abandon_payment`]: crate::ln::channelmanager::ChannelManager::abandon_payment
357-
/// [`ChannelManager::retry_payment`]: crate::ln::channelmanager::ChannelManager::retry_payment
353+
/// [`Event::PaymentPathFailed`]: crate::util::events::Event::PaymentPathFailed
354+
/// [`Event::PaymentFailed`]: crate::util::events::Event::PaymentFailed
358355
AllFailedResendSafe(Vec<APIError>),
359356
/// Indicates that a payment for the provided [`PaymentId`] is already in-flight and has not
360-
/// yet completed (i.e. generated an [`Event::PaymentSent`]) or been abandoned (via
361-
/// [`ChannelManager::abandon_payment`]).
357+
/// yet completed (i.e. generated an [`Event::PaymentSent`] or [`Event::PaymentFailed`]).
362358
///
363359
/// [`PaymentId`]: crate::ln::channelmanager::PaymentId
364360
/// [`Event::PaymentSent`]: crate::util::events::Event::PaymentSent
365-
/// [`ChannelManager::abandon_payment`]: crate::ln::channelmanager::ChannelManager::abandon_payment
361+
/// [`Event::PaymentFailed`]: crate::util::events::Event::PaymentFailed
366362
DuplicatePayment,
367363
/// Some paths which were attempted failed to send, though possibly not all. At least some
368-
/// paths have irrevocably committed to the HTLC and retrying the payment in full would result
369-
/// in over-/re-payment.
364+
/// paths have irrevocably committed to the HTLC.
370365
///
371366
/// The results here are ordered the same as the paths in the route object which was passed to
372-
/// send_payment, and any `Err`s which are not [`APIError::MonitorUpdateInProgress`] can be
373-
/// safely retried via [`ChannelManager::retry_payment`].
367+
/// send_payment.
374368
///
375-
/// Any entries which contain `Err(APIError::MonitorUpdateInprogress)` or `Ok(())` MUST NOT be
376-
/// retried as they will result in over-/re-payment. These HTLCs all either successfully sent
377-
/// (in the case of `Ok(())`) or will send once a [`MonitorEvent::Completed`] is provided for
378-
/// the next-hop channel with the latest update_id.
369+
/// Any entries which contain `Err(APIError::MonitorUpdateInprogress)` will send once a
370+
/// [`MonitorEvent::Completed`] is provided for the next-hop channel with the latest update_id.
379371
///
380-
/// [`ChannelManager::retry_payment`]: crate::ln::channelmanager::ChannelManager::retry_payment
381372
/// [`MonitorEvent::Completed`]: crate::chain::channelmonitor::MonitorEvent::Completed
382373
PartialFailure {
383-
/// The errors themselves, in the same order as the route hops.
374+
/// The errors themselves, in the same order as the paths from the route.
384375
results: Vec<Result<(), APIError>>,
385376
/// If some paths failed without irrevocably committing to the new HTLC(s), this will
386-
/// contain a [`RouteParameters`] object which can be used to calculate a new route that
387-
/// will pay all remaining unpaid balance.
377+
/// contain a [`RouteParameters`] object for the failing paths.
388378
failed_paths_retry: Option<RouteParameters>,
389379
/// The payment id for the payment, which is now at least partially pending.
390380
payment_id: PaymentId,
@@ -899,8 +889,8 @@ impl OutboundPayments {
899889
.map_err(|e| { self.remove_outbound_if_all_failed(payment_id, &e); e })
900890
}
901891

902-
// If we failed to send any paths, we should remove the new PaymentId from the
903-
// `pending_outbound_payments` map, as the user isn't expected to `abandon_payment`.
892+
// If we failed to send any paths, remove the new PaymentId from the `pending_outbound_payments`
893+
// map as the payment is free to be resent.
904894
fn remove_outbound_if_all_failed(&self, payment_id: PaymentId, err: &PaymentSendFailure) {
905895
if let &PaymentSendFailure::AllFailedResendSafe(_) = err {
906896
let removed = self.pending_outbound_payments.lock().unwrap().remove(&payment_id).is_some();

lightning/src/ln/payment_tests.rs

+12-52
Original file line numberDiff line numberDiff line change
@@ -228,55 +228,6 @@ fn mpp_receive_timeout() {
228228
do_mpp_receive_timeout(false);
229229
}
230230

231-
#[test]
232-
fn retry_expired_payment() {
233-
let chanmon_cfgs = create_chanmon_cfgs(3);
234-
let node_cfgs = create_node_cfgs(3, &chanmon_cfgs);
235-
let node_chanmgrs = create_node_chanmgrs(3, &node_cfgs, &[None, None, None]);
236-
let mut nodes = create_network(3, &node_cfgs, &node_chanmgrs);
237-
238-
let _chan_0 = create_announced_chan_between_nodes(&nodes, 0, 1);
239-
let chan_1 = create_announced_chan_between_nodes(&nodes, 2, 1);
240-
// Rebalance to find a route
241-
send_payment(&nodes[2], &vec!(&nodes[1])[..], 3_000_000);
242-
243-
let (route, payment_hash, _, payment_secret) = get_route_and_payment_hash!(nodes[0], nodes[2], 100_000);
244-
245-
// Rebalance so that the first hop fails.
246-
send_payment(&nodes[1], &vec!(&nodes[2])[..], 2_000_000);
247-
248-
// Make sure the payment fails on the first hop.
249-
nodes[0].node.send_payment(&route, payment_hash, &Some(payment_secret), PaymentId(payment_hash.0)).unwrap();
250-
check_added_monitors!(nodes[0], 1);
251-
let mut events = nodes[0].node.get_and_clear_pending_msg_events();
252-
assert_eq!(events.len(), 1);
253-
let mut payment_event = SendEvent::from_event(events.pop().unwrap());
254-
nodes[1].node.handle_update_add_htlc(&nodes[0].node.get_our_node_id(), &payment_event.msgs[0]);
255-
check_added_monitors!(nodes[1], 0);
256-
commitment_signed_dance!(nodes[1], nodes[0], payment_event.commitment_msg, false);
257-
expect_pending_htlcs_forwardable!(nodes[1]);
258-
expect_pending_htlcs_forwardable_and_htlc_handling_failed!(&nodes[1], vec![HTLCDestination::NextHopChannel { node_id: Some(nodes[2].node.get_our_node_id()), channel_id: chan_1.2 }]);
259-
let htlc_updates = get_htlc_update_msgs!(nodes[1], nodes[0].node.get_our_node_id());
260-
assert!(htlc_updates.update_add_htlcs.is_empty());
261-
assert_eq!(htlc_updates.update_fail_htlcs.len(), 1);
262-
assert!(htlc_updates.update_fulfill_htlcs.is_empty());
263-
assert!(htlc_updates.update_fail_malformed_htlcs.is_empty());
264-
check_added_monitors!(nodes[1], 1);
265-
nodes[0].node.handle_update_fail_htlc(&nodes[1].node.get_our_node_id(), &htlc_updates.update_fail_htlcs[0]);
266-
commitment_signed_dance!(nodes[0], nodes[1], htlc_updates.commitment_signed, false);
267-
expect_payment_failed!(nodes[0], payment_hash, false);
268-
269-
// Mine blocks so the payment will have expired.
270-
connect_blocks(&nodes[0], 3);
271-
272-
// Retry the payment and make sure it errors as expected.
273-
if let Err(PaymentSendFailure::ParameterError(APIError::APIMisuseError { err })) = nodes[0].node.retry_payment(&route, PaymentId(payment_hash.0)) {
274-
assert!(err.contains("not found"));
275-
} else {
276-
panic!("Unexpected error");
277-
}
278-
}
279-
280231
#[test]
281232
fn no_pending_leak_on_initial_send_failure() {
282233
// In an earlier version of our payment tracking, we'd have a retry entry even when the initial
@@ -570,7 +521,10 @@ fn do_test_completed_payment_not_retryable_on_reload(use_dust: bool) {
570521
// If we attempt to retry prior to the HTLC-Timeout (or commitment transaction, for dust HTLCs)
571522
// confirming, we will fail as it's considered still-pending...
572523
let (new_route, _, _, _) = get_route_and_payment_hash!(nodes[0], nodes[2], if use_dust { 1_000 } else { 1_000_000 });
573-
assert!(nodes[0].node.retry_payment(&new_route, payment_id).is_err());
524+
match nodes[0].node.send_payment(&new_route, payment_hash, &Some(payment_secret), payment_id) {
525+
Err(PaymentSendFailure::DuplicatePayment) => {},
526+
_ => panic!("Unexpected error")
527+
}
574528
assert!(nodes[0].node.get_and_clear_pending_msg_events().is_empty());
575529

576530
// After ANTI_REORG_DELAY confirmations, the HTLC should be failed and we can try the payment
@@ -600,7 +554,10 @@ fn do_test_completed_payment_not_retryable_on_reload(use_dust: bool) {
600554
pass_along_route(&nodes[0], &[&[&nodes[1], &nodes[2]]], if use_dust { 1_000 } else { 1_000_000 }, payment_hash, payment_secret);
601555
claim_payment(&nodes[0], &[&nodes[1], &nodes[2]], payment_preimage);
602556

603-
assert!(nodes[0].node.send_payment(&new_route, payment_hash, &Some(payment_secret), payment_id).is_err());
557+
match nodes[0].node.send_payment(&new_route, payment_hash, &Some(payment_secret), payment_id) {
558+
Err(PaymentSendFailure::DuplicatePayment) => {},
559+
_ => panic!("Unexpected error")
560+
}
604561
assert!(nodes[0].node.get_and_clear_pending_msg_events().is_empty());
605562

606563
let chan_0_monitor_serialized = get_monitor!(nodes[0], chan_id).encode();
@@ -614,7 +571,10 @@ fn do_test_completed_payment_not_retryable_on_reload(use_dust: bool) {
614571

615572
reconnect_nodes(&nodes[0], &nodes[1], (false, false), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (false, false));
616573

617-
assert!(nodes[0].node.retry_payment(&new_route, payment_id).is_err());
574+
match nodes[0].node.send_payment(&new_route, payment_hash, &Some(payment_secret), payment_id) {
575+
Err(PaymentSendFailure::DuplicatePayment) => {},
576+
_ => panic!("Unexpected error")
577+
}
618578
assert!(nodes[0].node.get_and_clear_pending_msg_events().is_empty());
619579
}
620580

lightning/src/routing/router.rs

+1-1
Original file line numberDiff line numberDiff line change
@@ -360,7 +360,7 @@ impl Readable for Route {
360360
/// Parameters needed to find a [`Route`].
361361
///
362362
/// Passed to [`find_route`] and [`build_route_from_hops`], but also provided in
363-
/// [`Event::PaymentPathFailed`] for retrying a failed payment path.
363+
/// [`Event::PaymentPathFailed`].
364364
///
365365
/// [`Event::PaymentPathFailed`]: crate::util::events::Event::PaymentPathFailed
366366
#[derive(Clone, Debug, PartialEq, Eq)]

0 commit comments

Comments
 (0)