LOOP-in Failed: FailedPrecondition desc = target unreachable

[silenzara]

I'm trying to do a loop-in via the static address. My loop channel has plenty of inbound to receive the loop-in but I'm consistently getting the same error for the past few hours:

2025-05-13 08:05:15.237 [WRN] LOOP: Server probe error: rpc error: code = FailedPrecondition desc = target unreachable
2025-05-13 08:17:44.678 [WRN] LOOP: Server probe error: rpc error: code = FailedPrecondition desc = target unreachable
2025-05-13 08:29:58.831 [WRN] LOOP: Server probe error: rpc error: code = FailedPrecondition desc = target unreachable
2025-05-13 08:40:58.861 [WRN] LOOP: Server probe error: rpc error: code = FailedPrecondition desc = target unreachable
2025-05-13 08:55:37.997 [WRN] LOOP: Server probe error: rpc error: code = FailedPrecondition desc = target unreachable
2025-05-13 09:06:06.184 [WRN] LOOP: Server probe error: rpc error: code = FailedPrecondition desc = target unreachable

This happens when I run the command loop quote in --last_hop 021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d --deposit_outpoint xxxxx:n

I am able to send sats via loop to my node so I know the channel is operational.

This behavior is not new to me, I've encountered it on a few earlier occasions in the past 1-2 years. Maybe 4-5 times total. Because the problem keeps reappearing I decided to document it here.

To speculate a bit on the root cause (I could be completely wrong though), I think it is related to an underlying networking issue. For the past week the loop node has been very unstable for me. I suspect it is also unstable for other loop peers because I've seen many loop channels being disable from both ends at the times I was having connection issues.

Since restarting my node about 5 days ago I have a flap_count of 1129. This is much more than any other node I'm peering with.

Since I've started noticing something was going on with my loop connection I've starting doing probes on a 120 second interval to test for latency. This is what that log shows: https://gist.github.com/silenzara/7f0531e9f81e7ec4beb5ae377405f305

The log does not show a date but the log contains data from the past 3.5 days. As you can see the connection is very unstable, often the latency is very high or no connection at all (log shows "-------").
I also ran the same probe to OKX, a node that should probably have a much less stable connection but it shows very stable latencies with only very rarely a time above 1000ms.

My LND logs also show many lines related to loop, for example:

• disconnecting 021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d@50.112.125.89:9735, reason: unable to start peer: unable to read init msg: read next header: EOF
• Starting peer=021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d got error: unable to read init msg: read next header: EOF
• Peer(021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d): unable to read message from peer: read next header: EOF
• pong response failure for 021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d@44.228.158.82:9735: timeout while waiting for pong response -- disconnecting

My theory is that during times of connection instability a probe is being done (either my loop-in or from another loop client) and this fails because of timeout or other possible reasons. This gets recorded in the mc and if it happens often enough then the loop mc thinks the channel is not usable.

I'm running: loop version 0.31.1-beta commit= with 0.18.5-beta commit=v0.18.5-beta

[levmi]

We think this should be fixed now. We've made some fixes with regard stability via some LND fixes along with some fixes to Loop In pathfinding flows. Definitely re-open if this issue pops back up, but for now, we're going to close this issue.