Track channels which a given payment part failed to traverse
authorMatt Corallo <git@bluematt.me>
Wed, 6 Jul 2022 19:17:40 +0000 (19:17 +0000)
committerMatt Corallo <git@bluematt.me>
Thu, 14 Jul 2022 18:37:25 +0000 (18:37 +0000)
commit93e645daf46f85949ae0edf60d36bf21e9fde8af
tree7f764e5021d20b6c2e422337a92dc7b366def261
parent5cca9a0696032fc3c4aba7920afbe24ce0235ff9
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.
lightning/src/ln/channelmanager.rs
lightning/src/ln/functional_test_utils.rs
lightning/src/routing/router.rs