Matt Corallo 93e645daf4 Track channels which a given payment part failed to traverse ... When an HTLC fails, we currently rely on the scorer learning the failed channel and assigning an infinite (`u64::max_value()`) penalty to the channel so as to avoid retrying over the exact same path (if there's only one available path). This is common when trying to pay a mobile client behind an LSP if the mobile client is currently offline. This leads to the scorer being overly conservative in some cases - returning `u64::max_value()` when a given path hasn't been tried for a given payment may not be the best decision, even if that channel failed 50 minutes ago. By tracking channels which failed on a payment part level and explicitly refusing to route over them we can relax the requirements on the scorer, allowing it to make different decisions on how to treat channels that failed relatively recently without causing payments to retry the same path forever. This does have the drawback that it could allow two separate part of a payment to traverse the same path even though that path just failed, however this should only occur if the payment is going to fail anyway, at least as long as the scorer is properly learning. Closes #1241, superseding #1252.		2022-07-14 18:37:25 +00:00
..
src	Track channels which a given payment part failed to traverse	2022-07-14 18:37:25 +00:00
Cargo.toml	Bump crate versions to 0.0.109/invoice 0.17	2022-07-01 16:05:33 +00:00