Skip to content

Ensure we don't ever retry a payment along a just-failed path #1252

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Ensure we don't ever retry a payment along a just-failed path #1252

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
83 changes: 67 additions & 16 deletions lightning-invoice/src/payment.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -382,7 +382,7 @@ where
// recipient may misbehave and claim the funds, at which point we have to
// consider the payment sent, so return `Ok()` here, ignoring any retry
// errors.
let _ = self.retry_payment(payment_id, payment_hash, &retry_data);
let _ = self.retry_payment(payment_id, payment_hash, &retry_data, None);
Ok(payment_id)
} else {
// This may happen if we send a payment and some paths fail, but
Expand All @@ -396,8 +396,8 @@ where
}.map_err(|e| PaymentError::Sending(e))
}

fn retry_payment(
&self, payment_id: PaymentId, payment_hash: PaymentHash, params: &RouteParameters
fn retry_payment(&self, payment_id: PaymentId, payment_hash: PaymentHash,
params: &RouteParameters, avoid_scid: Option<u64>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this would be cleaner if part of the RouteParameters.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And avoided directly in find_route, that is.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean passing it through to the router itself and asking it to completely avoid an SCID? That feels like its better done via the Score implementer, which I guess is ultimately the problem here - that the Scorer in use int he sample (ie our default one) doesn't strictly refuse to pay over a channel that just failed. That said, I do feel like the InvoicePayer should be robust against a braindead scorer, whether its our own or a user-provided one, so it feels nice to have it here too?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, but also don't put the onus on the event handler to set it and pass it to find_route. Simply have the ChannelManager set it when creating the PaymentPathFailed event. Then it is completely transparent to anyone handling the event.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, I do feel like "avoid this channel" is really more of a Score thing than a router thing - we have a whole interface for it, it seems annoying to duplicate that interface here. Its not a lot of code change, but still awkward.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm... but this use case is (a) ephemeral as it only applies to a specific payment -- lower payment amounts may be successful for another payment or even the failed path if further split on retry -- and (b) being handled by the caller not the scorer in this PR.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right in this instance its strangely dual-caller-scorer handling it - the scorer de-prioritizes and the caller handles the "oh, this went wrong, we cant do this, scorer or router are busted" case. I guess two more practical questions on behavior that may inform this more:

a) do we want to track this information across payment attempts - if there's two available last-hop hints do we want to just go back and forth between them until we run out of attempts,
b) do we care about avoiding the path in the router or are we okay with failing if we find the same path again (ie if the scorer is broken or doesn't learn, are we okay just failing the payment vs making sure the router picks another path)?

Both imply that the data should be in the RouteParameters, I think, if we care about either (I'm not sure we do), but (a) implies it should be in the Payee (to be renamed) not RouteParameters, even.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussed this more offline, sounds like we want to/should go with moving the logic as described here, will do.

) -> Result<(), ()> {
let max_payment_attempts = self.retry_attempts.0 + 1;
let attempts = *self.payment_cache.lock().unwrap()
Expand All @@ -419,29 +419,42 @@ where

let payer = self.payer.node_id();
let first_hops = self.payer.first_hops();
let route = self.router.find_route(
&payer, &params, &payment_hash, Some(&first_hops.iter().collect::<Vec<_>>()),
&self.scorer.lock()
);
if route.is_err() {
log_trace!(self.logger, "Failed to find a route for payment {}; not retrying (attempts: {})", log_bytes!(payment_hash.0), attempts);
let route = match self.router.find_route(
&payer, &params, &payment_hash, Some(&first_hops.iter().collect::<Vec<_>>()), &self.scorer.lock()
) {
Ok(r) => r,
Err(_) => {
log_trace!(self.logger, "Failed to find a route for payment {}; not retrying (attempts: {})", log_bytes!(payment_hash.0), attempts);
return Err(());
}
};

if route.paths.iter().any(|path| path.iter().any(|hop| Some(hop.short_channel_id) == avoid_scid)) {
// While hopefully there is a Scor being used to avoid taking channels which *just*
// failed, its possible that there is simply no other route. This is common in cases
// where we're paying a node which is behind some form of LSP - there is a single route
// hint which we are required to pay through. If that route hint failed (ie the node we
// are trying to pay is offline), we shouldn't try to pay the node again and again
// through the same hop.
log_trace!(self.logger, "Route found for payment {} re-uses just-failed channel {}; not retrying (attempts: {})",
log_bytes!(payment_hash.0), avoid_scid.unwrap_or(0),attempts);
return Err(());
}

match self.payer.retry_payment(&route.unwrap(), payment_id) {
match self.payer.retry_payment(&route, payment_id) {
Ok(()) => Ok(()),
Err(PaymentSendFailure::ParameterError(_)) |
Err(PaymentSendFailure::PathParameterError(_)) => {
log_trace!(self.logger, "Failed to retry for payment {} due to bogus route/payment data, not retrying.", log_bytes!(payment_hash.0));
Err(())
},
Err(PaymentSendFailure::AllFailedRetrySafe(_)) => {
self.retry_payment(payment_id, payment_hash, params)
self.retry_payment(payment_id, payment_hash, params, avoid_scid)
},
Err(PaymentSendFailure::PartialFailure { failed_paths_retry, .. }) => {
if let Some(retry) = failed_paths_retry {
// Always return Ok for the same reason as noted in pay_internal.
let _ = self.retry_payment(payment_id, payment_hash, &retry);
let _ = self.retry_payment(payment_id, payment_hash, &retry, avoid_scid);
}
Ok(())
},
Expand Down Expand Up @@ -493,7 +506,7 @@ where
} else if retry.is_none() {
log_trace!(self.logger, "Payment {} missing retry params; not retrying", log_bytes!(payment_hash.0));
self.payer.abandon_payment(payment_id.unwrap());
} else if self.retry_payment(payment_id.unwrap(), *payment_hash, retry.as_ref().unwrap()).is_ok() {
} else if self.retry_payment(payment_id.unwrap(), *payment_hash, retry.as_ref().unwrap(), *short_channel_id).is_ok() {
// We retried at least somewhat, don't provide the PaymentPathFailed event to the user.
return;
} else {
Expand Down Expand Up @@ -971,6 +984,40 @@ mod tests {
assert_eq!(*payer.attempts.borrow(), 1);
}

#[test]
fn fails_paying_invoice_after_rejected_at_only_last_hop() {
let event_handled = core::cell::RefCell::new(false);
let event_handler = |_: &_| { *event_handled.borrow_mut() = true; };

let payment_preimage = PaymentPreimage([1; 32]);
let invoice = invoice(payment_preimage);
let final_value_msat = invoice.amount_milli_satoshis().unwrap();

let payer = TestPayer::new().expect_send(Amount::ForInvoice(final_value_msat));
let router = TestRouter {};
let scorer = RefCell::new(TestScorer::new());
let logger = TestLogger::new();
let invoice_payer =
InvoicePayer::new(&payer, router, &scorer, &logger, event_handler, RetryAttempts(2));

let payment_id = Some(invoice_payer.pay_invoice(&invoice).unwrap());
assert_eq!(*payer.attempts.borrow(), 1);

let event = Event::PaymentPathFailed {
payment_id,
payment_hash: PaymentHash(invoice.payment_hash().clone().into_inner()),
network_update: None,
rejected_by_dest: false,
all_paths_failed: false,
path: vec![],
short_channel_id: Some(1),
retry: Some(TestRouter::retry_for_invoice(&invoice)),
};
invoice_payer.handle_event(&event);
assert_eq!(*event_handled.borrow(), true);
assert_eq!(*payer.attempts.borrow(), 1);
}

#[test]
fn fails_repaying_invoice_with_pending_payment() {
let event_handled = core::cell::RefCell::new(false);
Expand Down Expand Up @@ -1175,8 +1222,7 @@ mod tests {

// Expect that scorer is given short_channel_id upon handling the event.
let payer = TestPayer::new()
.expect_send(Amount::ForInvoice(final_value_msat))
.expect_send(Amount::OnRetry(final_value_msat / 2));
.expect_send(Amount::ForInvoice(final_value_msat));
let router = TestRouter {};
let scorer = RefCell::new(TestScorer::new().expect(PaymentPath::Failure {
path: path.clone(), short_channel_id: path[0].short_channel_id,
Expand Down Expand Up @@ -1634,6 +1680,8 @@ mod tests {

let chan_1_scid = create_announced_chan_between_nodes_with_value(&nodes, 0, 1, 10_000_000, 0, InitFeatures::known(), InitFeatures::known()).0.contents.short_channel_id;
let chan_2_scid = create_announced_chan_between_nodes_with_value(&nodes, 1, 2, 10_000_000, 0, InitFeatures::known(), InitFeatures::known()).0.contents.short_channel_id;
let chan_3_scid = create_announced_chan_between_nodes_with_value(&nodes, 0, 1, 10_000_000, 0, InitFeatures::known(), InitFeatures::known()).0.contents.short_channel_id;
let chan_4_scid = create_announced_chan_between_nodes_with_value(&nodes, 1, 2, 10_000_000, 0, InitFeatures::known(), InitFeatures::known()).0.contents.short_channel_id;

let mut route = Route {
paths: vec![
Expand Down Expand Up @@ -1672,8 +1720,11 @@ mod tests {
};
let router = ManualRouter(RefCell::new(VecDeque::new()));
router.expect_find_route(Ok(route.clone()));
// On retry, we'll only be asked for one path
// On retry, we'll only be asked for one path. We also give it a diffferent SCID set as the
// InvoicePayer will refuse to retry using a just-failed channel.
route.paths.remove(1);
route.paths[0][0].short_channel_id = chan_3_scid;
route.paths[0][1].short_channel_id = chan_4_scid;
router.expect_find_route(Ok(route.clone()));

let expected_events: RefCell<VecDeque<&dyn Fn(&Event)>> = RefCell::new(VecDeque::new());
Expand Down