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

[rkfg]

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.

[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.

[rkfg]

Here's the log when the payment fails and Bob is offline: I tried to clear the blacklist but it doesn't seem to work:

>>> clear_ln_blacklist()
Traceback (most recent call last):
  File "/home/rkfg/.local/lib/python3.9/site-packages/electrum/gui/qt/main_window.py", line 2213, in <lambda>
    return lambda *args, **kwargs: f(method,
  File "/home/rkfg/.local/lib/python3.9/site-packages/electrum/commands.py", line 181, in _run
    result = fut.result()
  File "/usr/lib/python3.9/concurrent/futures/_base.py", line 440, in result
    return self.__get_result()
  File "/usr/lib/python3.9/concurrent/futures/_base.py", line 389, in __get_result
    raise self._exception
  File "/home/rkfg/.local/lib/python3.9/site-packages/electrum/commands.py", line 144, in func_wrapper
    return await func(*args, **kwargs)
  File "/home/rkfg/.local/lib/python3.9/site-packages/electrum/commands.py", line 1092, in clear_ln_blacklist
    self.network.path_finder.blacklist.clear()
AttributeError: 'LNPathFinder' object has no attribute 'blacklist'

[bitromortac]

Could you try with master? There it should work clearing the blacklist.

[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.

[SomberNight]

Any idea which of those onion errors are sent by the second-to-last node (i.e. the node that has a direct channel with the payee)?

I am wondering what the "expected" error is in this case ("next hop offline")... is it CHANNEL_DISABLED?

[rkfg]

No idea. Is there an option to dump the routes that Electrum tries? lnd does so by default and it's very informative.

[SomberNight]

No, the routes are not exposed to the GUI atm. You can see them in the logs though. Note that in this specific example you could tell which attempts correspond to errors coming from the second-to-last-node by checking whether the (short) Channel ID corresponds to one of the the recipient's channels.