@@ -1163,8 +1163,8 @@ pub enum RecentPaymentDetails {
11631163 /// Hash of the payment that is currently being sent but has yet to be fulfilled or
11641164 /// abandoned.
11651165 payment_hash : PaymentHash ,
1166- /// Total amount (in msat) across all paths for this payment, not just the amount currently
1167- /// inflight.
1166+ /// Total amount (in msat, excluding fees ) across all paths for this payment,
1167+ /// not just the amount currently inflight.
11681168 total_msat : u64 ,
11691169 } ,
11701170 /// When a pending payment is fulfilled, we continue tracking it until all pending HTLCs have
@@ -2476,6 +2476,8 @@ where
24762476 /// Value parameters are provided via the last hop in route, see documentation for RouteHop
24772477 /// fields for more info.
24782478 ///
2479+ /// # Avoiding Duplicate Payments
2480+ ///
24792481 /// If a pending payment is currently in-flight with the same [`PaymentId`] provided, this
24802482 /// method will error with an [`APIError::InvalidRoute`]. Note, however, that once a payment
24812483 /// is no longer pending (either via [`ChannelManager::abandon_payment`], or handling of an
@@ -2488,12 +2490,19 @@ where
24882490 /// consider using the [`PaymentHash`] as the key for tracking payments. In that case, the
24892491 /// [`PaymentId`] should be a copy of the [`PaymentHash`] bytes.
24902492 ///
2493+ /// Additionally, in the scenario where we begin the process of sending a payment, but crash
2494+ /// before `send_payment` returns (or prior to [`ChannelMonitorUpdate`] persistence if you're
2495+ /// using [`ChannelMonitorUpdateStatus::InProgress`]), the payment may be lost on restart. See
2496+ /// [`ChannelManager::list_recent_payments`] for more information.
2497+ ///
24912498 /// May generate SendHTLCs message(s) event on success, which should be relayed (e.g. via
24922499 /// [`PeerManager::process_events`]).
24932500 ///
2501+ /// # Possible Error States on PaymentSendFailure
2502+ ///
24942503 /// Each path may have a different return value, and PaymentSendValue may return a Vec with
24952504 /// each entry matching the corresponding-index entry in the route paths, see
2496- /// PaymentSendFailure for more info.
2505+ /// [` PaymentSendFailure`] for more info.
24972506 ///
24982507 /// In general, a path may raise:
24992508 /// * [`APIError::InvalidRoute`] when an invalid route or forwarding parameter (cltv_delta, fee,
@@ -2508,20 +2517,17 @@ where
25082517 /// irrevocably committed to on our end. In such a case, do NOT retry the payment with a
25092518 /// different route unless you intend to pay twice!
25102519 ///
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.
2520+ /// # A caution on `payment_secret`
25152521 ///
2516- /// payment_secret is unrelated to payment_hash (or PaymentPreimage) and exists to authenticate
2517- /// the sender to the recipient and prevent payment-probing (deanonymization) attacks. For
2518- /// newer nodes, it will be provided to you in the invoice. If you do not have one, the Route
2519- /// must not contain multiple paths as multi-path payments require a recipient-provided
2520- /// payment_secret.
2522+ /// ` payment_secret` is unrelated to ` payment_hash` (or [` PaymentPreimage`] ) and exists to
2523+ /// authenticate the sender to the recipient and prevent payment-probing (deanonymization)
2524+ /// attacks. For newer nodes, it will be provided to you in the invoice. If you do not have one,
2525+ /// the Route must not contain multiple paths as multi-path payments require a
2526+ /// recipient-provided ` payment_secret` .
25212527 ///
2522- /// If a payment_secret *is* provided, we assume that the invoice had the payment_secret feature
2523- /// bit set (either as required or as available). If multiple paths are present in the Route,
2524- /// we assume the invoice had the basic_mpp feature set.
2528+ /// If a ` payment_secret` *is* provided, we assume that the invoice had the payment_secret
2529+ /// feature bit set (either as required or as available). If multiple paths are present in the
2530+ /// Route, we assume the invoice had the basic_mpp feature set.
25252531 ///
25262532 /// [`Event::PaymentSent`]: events::Event::PaymentSent
25272533 /// [`PeerManager::process_events`]: crate::ln::peer_handler::PeerManager::process_events
0 commit comments