"No path found" error gets stuck after the offline destination comes online

This is about Lightning payments with gossip enabled and no trampoline routing. Testing the following case on 4.1.2:

• On testnet, run two instances of Electrum with different wallets, let’s call them Alice and Bob for conformity.
• They both open channels to some random nodes and have incoming liquidity, payments between them work fine.
• Alice wants to pay Bob
• Bob creates an invoice and sends it to Alice
• For whatever reason Bob goes offline (we close the wallet B)
• Alice pays the invoice but the process fails with “No path found”, which is fully expected and fine.
• Bob goes back online (we open the wallet B again) and notifies Alice.
• Alice clicks Retry on the payment.
• However, Electrum clearly doesn’t even try to find a path instantly returning the “No path found” error. At the same time, status of the payment changes from Failed to Expires in about 24 hours which is also confusing. The Log menu item also disappears.
• Alice restarts her Electrum (here you need to fully restart Electrum, not just close one of the wallets), waits until gossip is fully synchronized (important!) and chooses Pay... in the failed payment’s context menu.
• The payment should complete fine.

This error seems to be pretty sticky. If you only reopen the wallet without exiting Electrum (in case you run both Bob and Alice on the same machine) it doesn’t go away and instantly says “Path not found”. If you don’t wait until gossip is downloaded and try to pay you’ll get the same error, and it won’t go away even after gossip is synchronized. So Electrum needs to be restarted fully again.

It seems that when using trampoline all of this above doesn’t apply. As soon as the other node goes online it can be paid with a simple retry.

[rkfg]

Yes, sorry. Just checked with master and indeed clearing the blacklist helped to resolve it. I suppose it should be done automatically if the user retries a failed payment, also the Failed status shouldn’t disappear like that together with the log.

[bitromortac]

Thanks for the report. What’s the onion error you get back in the log for the last hop? This behavior is probably because the onion error handling blacklists the receiving channel and the blacklist gets reset after restarting. Could you try clear_ln_blacklist() in the console? There is some work going on in this area right now and we could exempt the last part of the route from getting blacklisted somehow.