I spent the day understanding and fixing a bug in lnd-manageJ's payment system. Turns out, Nicehash has two nodes, and two channels between those nodes. One worth 5 BTC (https://amboss.space/edge/917695285539373056), one just 0.01 BTC (https://amboss.space/edge/915246673132126208). Quite the difference. To make things worse, the smaller channel is free, while the larger one charges 1ppm. Not so much of a difference, but still.

While running a "top up" payment (rebalancing using Pickhardt payments), the larger channel was used first (because of the size it's deemed better than the smaller channel, despite the costs). My code learned that some decent amount is available on that channel, due to a failure further down the line. This information was then also propagated to the other, smaller, channel. In subsequent attempts, both channels were used: the smaller channel up to the maximum, the larger channel for the remainder. Sadly, the smaller channel actually was rather empty, which confused my code into running in circles.

After understanding this issue, I took the channel ID into account when storing and using this kind of liquidity information. This way, the larger channel and the smaller channel are treated individually, which seems good at first glance (and actually worked as expected, as far as I know).

However, with parallel channels between two nodes (at least when they share their fee settings), the forwarding lightning network server is free to pick any of these parallel channels. As such, if I request a route via channel ID 123, the actual channel used might be one with ID 456. This unexpected ID is also returned in failure responses, messing up the code I just "fixed".

In the end, I think I'm better off leaving the code "as is". Which means: combining the information I have about parallel channels. Which also means: routing between the two Nicehash nodes won't really work. Similar issues might exist for other nodes that have parallel channels with different fee settings.