Feature Request: Add practical MPP support to SendToRouteV2

[C-Otto]

Background

Continued from #5733.

Currently, SendToRouteV2 only has very minimal and extremely impractical support for MPP: if just one of the shards fails, it cannot be replaced. A single shard failure causes the whole MPP to fail. This is problematic as the successful shards cannot be cancelled (or settled) and need to time out before their funds can be reused.

Your environment

• lnd 0.13.1-beta

Steps to reproduce

Send MPP via SendToRouteV2 with two shards, one of them successful (reaching the destination), one of the failing (ending in some "temporary channel failure" due to lack of funds).

Expected behaviour

I can send a shard to replace the failing shard, (hopefully) completing the payment.

Actual behaviour

The payment cannot be re-used or completed. The successful shard blocks funds until it times out.

[renepickhardt]

Very strong ACK! This would also allow others and me to test my results more easily on top of lnd by wrapping the simulation at renepickhardt/mpp-splitter#11 I can do it if I collaborate with a given recipient if the recieving node allows me to send to various payment hashes and he keeps all of them and knows they belong to the same virtual MPP payment but this prevents me from conducting proper mainnet tests. As @Roasbeef mentioned in #5988 (comment) that testing is probably of highest importance I would love to see this prioritized a bit higher.

[renepickhardt]

Fyi in case Java is too much hustle I released a standalone python package of our "reference implementation" for optimally reliable payment flows at https://github.com/renepickhardt/pickhardtpayments

I think a very simple mainnet test can be done by

A) bring own oracleLightningNetwork class as a wrapper to the not existing and here requested mpp api. (msybe you could also include python to go for tests?)
B) make the pay command in the payment session class async
C) you need to map the lnd channelgraph format basically to the cln one (or write withe data import (c.f: renepickhardt/pickhardtpayments#5 )

Ofc some other constraints (htlc limits are not considered so I would not run this in production) but it should be fairly straight forward to conduct your own mainnet tests with this.

Fyi @guggero

PS @Roasbeef : the min cost flow solver is constantly below 100ms. However the overall runtime is much higher because for my own convenience I used the very slow networkx python package as the code I provide is for testing and education and not for production. So please don't do runtime benchmarks with this lib as the results will be very skewed due to networkx

[C-Otto]

I had a look at the code and found something that could be a bug.

To me it sounds like a non-terminal failure is set with the intention of "it's just a bad route", but this failure is treated as terminal. As such, the whole MPP is "dead".

Sets generic "NO_ROUTE" error:
https://github.com/lightningnetwork/lnd/blob/master/routing/router.go#L2274

Comment just a few lines above indicating that NO_ROUTE is not a terminal error:

Process the error to check if it maps into a terminal error code, if not use a generic NO_ROUTE error.
https://github.com/lightningnetwork/lnd/blob/master/routing/router.go#L2266

MPP failure reason

NOTE: Will only be set once the daemon has given up on the payment altogether.
https://github.com/lightningnetwork/lnd/blob/master/channeldb/mp_payment.go#L168

"is terminal failure" treats ANY failure reason as terminal:
https://github.com/lightningnetwork/lnd/blob/master/channeldb/mp_payment.go#L179

[C-Otto]

Related explanation in linked issue: #5733 (comment)