@@ -4615,24 +4615,32 @@ where
4615
4615
}
4616
4616
}
4617
4617
4618
- /// Sends a payment along a given route.
4619
- ///
4620
- /// This method is *DEPRECATED*, use [`Self::send_payment`] instead. If you wish to fix the
4621
- /// route for a payment, do so by matching the [`PaymentId`] passed to
4622
- /// [`Router::find_route_with_id`].
4623
- ///
4624
- /// Value parameters are provided via the last hop in route, see documentation for [`RouteHop`]
4625
- /// fields for more info.
4618
+ // Deprecated send method, for testing use [`Self::send_payment`] and
4619
+ // [`TestRouter::expect_find_route`] instead.
4620
+ //
4621
+ // [`TestRouter::expect_find_route`]: crate::util::test_utils::TestRouter::expect_find_route
4622
+ #[cfg(any(test, fuzzing))]
4623
+ pub fn send_payment_with_route(&self, route: Route, payment_hash: PaymentHash, recipient_onion: RecipientOnionFields, payment_id: PaymentId) -> Result<(), PaymentSendFailure> {
4624
+ let best_block_height = self.best_block.read().unwrap().height;
4625
+ let _persistence_guard = PersistenceNotifierGuard::notify_on_drop(self);
4626
+ self.pending_outbound_payments
4627
+ .send_payment_with_route(&route, payment_hash, recipient_onion, payment_id,
4628
+ &self.entropy_source, &self.node_signer, best_block_height,
4629
+ |args| self.send_payment_along_path(args))
4630
+ }
4631
+
4632
+ /// Sends a payment to the route found using the provided [`RouteParameters`], retrying failed
4633
+ /// payment paths based on the provided `Retry`.
4626
4634
///
4627
4635
/// May generate [`UpdateHTLCs`] message(s) event on success, which should be relayed (e.g. via
4628
4636
/// [`PeerManager::process_events`]).
4629
4637
///
4630
4638
/// # Avoiding Duplicate Payments
4631
4639
///
4632
4640
/// If a pending payment is currently in-flight with the same [`PaymentId`] provided, this
4633
- /// method will error with an [`APIError::InvalidRoute `]. Note, however, that once a payment
4634
- /// is no longer pending (either via [`ChannelManager::abandon_payment`], or handling of an
4635
- /// [`Event::PaymentSent`] or [`Event::PaymentFailed`]) LDK will not stop you from sending a
4641
+ /// method will error with [`RetryableSendFailure::DuplicatePayment `]. Note, however, that once a
4642
+ /// payment is no longer pending (either via [`ChannelManager::abandon_payment`], or handling of
4643
+ /// an [`Event::PaymentSent`] or [`Event::PaymentFailed`]) LDK will not stop you from sending a
4636
4644
/// second payment with the same [`PaymentId`].
4637
4645
///
4638
4646
/// Thus, in order to ensure duplicate payments are not sent, you should implement your own
@@ -4646,43 +4654,18 @@ where
4646
4654
/// using [`ChannelMonitorUpdateStatus::InProgress`]), the payment may be lost on restart. See
4647
4655
/// [`ChannelManager::list_recent_payments`] for more information.
4648
4656
///
4649
- /// # Possible Error States on [`PaymentSendFailure`]
4650
- ///
4651
- /// Each path may have a different return value, and [`PaymentSendFailure`] may return a `Vec` with
4652
- /// each entry matching the corresponding-index entry in the route paths, see
4653
- /// [`PaymentSendFailure`] for more info.
4654
- ///
4655
- /// In general, a path may raise:
4656
- /// * [`APIError::InvalidRoute`] when an invalid route or forwarding parameter (cltv_delta, fee,
4657
- /// node public key) is specified.
4658
- /// * [`APIError::ChannelUnavailable`] if the next-hop channel is not available as it has been
4659
- /// closed, doesn't exist, or the peer is currently disconnected.
4660
- /// * [`APIError::MonitorUpdateInProgress`] if a new monitor update failure prevented sending the
4661
- /// relevant updates.
4662
- ///
4663
- /// Note that depending on the type of the [`PaymentSendFailure`] the HTLC may have been
4664
- /// irrevocably committed to on our end. In such a case, do NOT retry the payment with a
4665
- /// different route unless you intend to pay twice!
4657
+ /// Routes are automatically found using the [`Router] provided on startup. To fix a route for a
4658
+ /// particular payment, match the [`PaymentId`] passed to [`Router::find_route_with_id`].
4666
4659
///
4667
- /// [`RouteHop`]: crate::routing::router::RouteHop
4668
4660
/// [`Event::PaymentSent`]: events::Event::PaymentSent
4669
4661
/// [`Event::PaymentFailed`]: events::Event::PaymentFailed
4670
4662
/// [`UpdateHTLCs`]: events::MessageSendEvent::UpdateHTLCs
4671
4663
/// [`PeerManager::process_events`]: crate::ln::peer_handler::PeerManager::process_events
4672
4664
/// [`ChannelMonitorUpdateStatus::InProgress`]: crate::chain::ChannelMonitorUpdateStatus::InProgress
4673
- #[cfg_attr(not(any(test, feature = "_test_utils")), deprecated(note = "Use `send_payment` instead"))]
4674
- pub fn send_payment_with_route(&self, route: Route, payment_hash: PaymentHash, recipient_onion: RecipientOnionFields, payment_id: PaymentId) -> Result<(), PaymentSendFailure> {
4675
- let best_block_height = self.best_block.read().unwrap().height;
4676
- let _persistence_guard = PersistenceNotifierGuard::notify_on_drop(self);
4677
- self.pending_outbound_payments
4678
- .send_payment_with_route(&route, payment_hash, recipient_onion, payment_id,
4679
- &self.entropy_source, &self.node_signer, best_block_height,
4680
- |args| self.send_payment_along_path(args))
4681
- }
4682
-
4683
- /// Similar to [`ChannelManager::send_payment_with_route`], but will automatically find a route based on
4684
- /// `route_params` and retry failed payment paths based on `retry_strategy`.
4685
- pub fn send_payment(&self, payment_hash: PaymentHash, recipient_onion: RecipientOnionFields, payment_id: PaymentId, route_params: RouteParameters, retry_strategy: Retry) -> Result<(), RetryableSendFailure> {
4665
+ pub fn send_payment(
4666
+ &self, payment_hash: PaymentHash, recipient_onion: RecipientOnionFields, payment_id: PaymentId,
4667
+ route_params: RouteParameters, retry_strategy: Retry
4668
+ ) -> Result<(), RetryableSendFailure> {
4686
4669
let best_block_height = self.best_block.read().unwrap().height;
4687
4670
let _persistence_guard = PersistenceNotifierGuard::notify_on_drop(self);
4688
4671
self.pending_outbound_payments
@@ -4897,8 +4880,26 @@ where
4897
4880
/// would be able to guess -- otherwise, an intermediate node may claim the payment and it will
4898
4881
/// never reach the recipient.
4899
4882
///
4900
- /// See [`send_payment`] documentation for more details on the return value of this function
4901
- /// and idempotency guarantees provided by the [`PaymentId`] key.
4883
+ /// See [`send_payment`] documentation for more details on the idempotency guarantees provided by
4884
+ /// the [`PaymentId`] key.
4885
+ ///
4886
+ /// # Possible Error States on [`PaymentSendFailure`]
4887
+ ///
4888
+ /// Each path may have a different return value, and [`PaymentSendFailure`] may return a `Vec` with
4889
+ /// each entry matching the corresponding-index entry in the route paths, see
4890
+ /// [`PaymentSendFailure`] for more info.
4891
+ ///
4892
+ /// In general, a path may raise:
4893
+ /// * [`APIError::InvalidRoute`] when an invalid route or forwarding parameter (cltv_delta, fee,
4894
+ /// node public key) is specified.
4895
+ /// * [`APIError::ChannelUnavailable`] if the next-hop channel is not available as it has been
4896
+ /// closed, doesn't exist, or the peer is currently disconnected.
4897
+ /// * [`APIError::MonitorUpdateInProgress`] if a new monitor update failure prevented sending the
4898
+ /// relevant updates.
4899
+ ///
4900
+ /// Note that depending on the type of the [`PaymentSendFailure`] the HTLC may have been
4901
+ /// irrevocably committed to on our end. In such a case, do NOT retry the payment with a
4902
+ /// different route unless you intend to pay twice!
4902
4903
///
4903
4904
/// Similar to regular payments, you MUST NOT reuse a `payment_preimage` value. See
4904
4905
/// [`send_payment`] for more information about the risks of duplicate preimage usage.
0 commit comments