robosats icon indicating copy to clipboard operation
robosats copied to clipboard

Consecutive failed routing retries (LND's mission control does not actually retry)

Open Reckless-Satoshi opened this issue 3 years ago • 1 comments

Observation: When a payout invoice fails routing, it will likely keep failing the next retries (every 5 mins). However, if the operator resets the mission control of LND lncli resetmc the payment can actually be successful.

Plausible explanation LND mission control (MC) avoids routes that it knows are out of liquidity due to previous failures, saving time and resources the next time it tries to send a payment. However, this might be counterproductive in a setting where the receiver has been notified 'he may lack inbound liquidity', since even if the receiver increases the inbound, the payment will keep failing (LND would not even try routing).

Submitting a new invoice does not help as the receiver pub_key is usually the same (unless the receiver has decided to use another wallet).

Fixes? Resetting mission control during retries is the easy solution. However, this means an increase on the overall time spent on retrying bad routes and might hinder scalability.

It might be possible in retries to replace SendPaymentV2 for SendToRouteV2 fed with routes found by QueryRoutes using param use_mission_control=False . Maybe there is a more straight forward way to tell SendPaymentV2 to ignore mission control.

There might also be different ways to configure LND MC that I have yet to explore.

Reckless-Satoshi avatar Jan 31 '22 13:01 Reckless-Satoshi

As of https://github.com/Reckless-Satoshi/robosats/commit/9da33b60e66449d09c1754fedaf8e7678cd64a57 mcreset has been disabled. Routing reliability and speed has improved considerably. Yet if a user's node if offline and he turns it online, the platform will not try to route to him (this case seems to not happen often at all).

Reckless-Satoshi avatar Jun 19 '22 13:06 Reckless-Satoshi