@@ -1726,7 +1726,7 @@ where
1726
1726
///
1727
1727
/// This can be useful for payments that may have been prepared, but ultimately not sent, as a
1728
1728
/// result of a crash. If such a payment exists, is not listed here, and an
1729
- /// [`Event::PaymentSent`] event has yet to be received, you may consider retrying the payment.
1729
+ /// [`Event::PaymentSent`] has not been received, you may consider retrying the payment.
1730
1730
///
1731
1731
/// [`Event::PaymentSent`]: events::Event::PaymentSent
1732
1732
pub fn list_recent_payments ( & self ) -> Vec < RecentPaymentDetails > {
@@ -2508,10 +2508,10 @@ where
2508
2508
/// irrevocably committed to on our end. In such a case, do NOT retry the payment with a
2509
2509
/// different route unless you intend to pay twice!
2510
2510
///
2511
- /// Additionally, if the process of sending a payment begins, but we crash before send_payment
2512
- /// returns (or prior to MonitorUpdate completion if you're using
2513
- /// [`ChannelMonitorUpdateStatus::InProgress`]), the payment may be lost on restart. See
2514
- /// [`ChannelManager::list_recent_payments`] for more information.
2511
+ /// Thus, in order to ensure duplicate payments are not sent, if we begin the process of sending
2512
+ /// a payment, but crash before `send_payment` returns (or prior to [`ChannelMonitorUpdate`]
2513
+ /// persistence if you're using [`ChannelMonitorUpdateStatus::InProgress`]), the payment may be
2514
+ /// lost on restart. See [`ChannelManager::list_recent_payments`] for more information.
2515
2515
///
2516
2516
/// payment_secret is unrelated to payment_hash (or PaymentPreimage) and exists to authenticate
2517
2517
/// the sender to the recipient and prevent payment-probing (deanonymization) attacks. For
0 commit comments