@@ -1163,8 +1163,8 @@ pub enum RecentPaymentDetails {
1163
1163
/// Hash of the payment that is currently being sent but has yet to be fulfilled or
1164
1164
/// abandoned.
1165
1165
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.
1168
1168
total_msat : u64 ,
1169
1169
} ,
1170
1170
/// When a pending payment is fulfilled, we continue tracking it until all pending HTLCs have
@@ -2476,6 +2476,8 @@ where
2476
2476
/// Value parameters are provided via the last hop in route, see documentation for RouteHop
2477
2477
/// fields for more info.
2478
2478
///
2479
+ /// # Avoiding Duplicate Payments
2480
+ ///
2479
2481
/// If a pending payment is currently in-flight with the same [`PaymentId`] provided, this
2480
2482
/// method will error with an [`APIError::InvalidRoute`]. Note, however, that once a payment
2481
2483
/// is no longer pending (either via [`ChannelManager::abandon_payment`], or handling of an
@@ -2488,12 +2490,19 @@ where
2488
2490
/// consider using the [`PaymentHash`] as the key for tracking payments. In that case, the
2489
2491
/// [`PaymentId`] should be a copy of the [`PaymentHash`] bytes.
2490
2492
///
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
+ ///
2491
2498
/// May generate SendHTLCs message(s) event on success, which should be relayed (e.g. via
2492
2499
/// [`PeerManager::process_events`]).
2493
2500
///
2501
+ /// # Possible Error States on PaymentSendFailure
2502
+ ///
2494
2503
/// Each path may have a different return value, and PaymentSendValue may return a Vec with
2495
2504
/// each entry matching the corresponding-index entry in the route paths, see
2496
- /// PaymentSendFailure for more info.
2505
+ /// [` PaymentSendFailure`] for more info.
2497
2506
///
2498
2507
/// In general, a path may raise:
2499
2508
/// * [`APIError::InvalidRoute`] when an invalid route or forwarding parameter (cltv_delta, fee,
@@ -2508,20 +2517,17 @@ where
2508
2517
/// irrevocably committed to on our end. In such a case, do NOT retry the payment with a
2509
2518
/// different route unless you intend to pay twice!
2510
2519
///
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`
2515
2521
///
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` .
2521
2527
///
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.
2525
2531
///
2526
2532
/// [`Event::PaymentSent`]: events::Event::PaymentSent
2527
2533
/// [`PeerManager::process_events`]: crate::ln::peer_handler::PeerManager::process_events
0 commit comments