[feature]: with SendPaymentV2, tell us that the fee limit is just too low instead of giving FAILURE_REASON_NO_ROUTE

[ZZiigguurraatt]

Often times the fee limit will be too low and we get a FAILURE_REASON_NO_ROUTE error. This can happen to both new and experienced users, wasting a lot of time thinking there is a path finding problem. It's even easier to miss this as a new user because the suggestions in #7832 have not been implemented.

It would very nice to get a a clearer message, FAILURE_REASON_INSUFFICIENT_FEE instead.

We have QueryRoutes that can determine a route at various fee_limit values and give a success probability. SendPaymentV2 should be able to automatically iterate on different fee_limit values and tell us the minimum fee we could theoretically pay and get a route. We also have EstimateRouteFee which appears to do some kind of probing to determine a fee that you could pay under real conditions. I feel like both of these technologies could be combined to give not only a FAILURE_REASON_INSUFFICIENT_FEE instead of a FAILURE_REASON_NO_ROUTE, but also suggest a minimum fee that we should consider trying in order to get a successful payment.

[alexbosworth]

Returning "insufficient fee" kind of implies that there is a working route available with a higher fee, which is potentially not the case and maybe even most likely the case. Maybe it could instead just make things more clear that it's exhausted the search space? So no_route_within_specified_fee_and_cltv_constraints or something like that or have a little message attached to reinforce that or just improve docs?

[ZZiigguurraatt]

I'm not suggesting to just change FAILURE_REASON_NO_ROUTE to FAILURE_REASON_INSUFFICIENT_FEE, but instead show a more specific error if there is a working route available with a higher fee. FAILURE_REASON_NO_ROUTE should still be used if there is actually no route that can be found.

There are many times both when I was a new user to lnd on test net and main net years ago when I read all about the lightning network and learned that I needed to have channels setup and I feel all good that I did setup all channels as I thought I should, then I can't figure out why I can't route a payment when I have the required topology in place.

Even now years later I try to do testing of an application on mainnet. I first do a lot of work between two personal nodes that I control so if something goes wrong with my application, it doesn't really matter. I don't have any fees with a direct channel, so I get everything working and feel real good about myself, then I try to close that direct channel and then open up channels between my two test nodes with a third party node and I get the FAILURE_REASON_NO_ROUTE error when I know both nodes are connected to the same third party node, but in fact, I just forgot that SendPaymentV2 has a default fee limit of 0.

I also recently setup a small regtest network for testing the new taproot assets and I run into a similar problem and this stupid mistake catches me again. I spend a lot of time thinking it is a problem with taproot assets, but in fact, it is just that SendPaymentV2 has a default fee limit of 0 and I don't realize that's the problem because the error message acts like I don't have a proper route (but I knew I did because I built the regtest network).

[alexbosworth]

Yeah that 0 default does seem like a footgun, I think the CLI actually works differently and forces you to choose a fee limit but the gRPC might need a restructuring or a new boolean to add that behavior to the API

[ZZiigguurraatt]

Yes, as mentioned above, #7832 suggests restructuring the gRPC call, but I think that should be done in addition the adding the features I've requested in this issue.