Potential race condition in channel gossip #2479
Comments
|
There's always a possibility this race happens because we don't have a way of adding the Since it's just an integration test, in the meantime, you could either add a small delay when processing |
|
This shouldn't make the channel unroutable - if our peer sends us an update about our own channel we store the fee info in the ChannelManager itself, which is then used in routing via the first-hop ChannelDetails. For our own channels we should never be looking at the network graph at all. |
|
Closing as probably-not-a-bug, but feel free to respond if you learn anything else or if the above doesn't work in your use-case for some reason! |
From my testing this doesn't seem to happen, maybe we are trying to get the route in a weird way? We are using |
|
Hmm, can you give more specifics? As long as the |
|
I gave it a shot and it didn't work: I believe this happens because we are trying to construct a route from a given node back to "us" (the node performing the call), so having the first_hops available doesn't help. What we are trying to do is building a route that goes from node A to B and then back to A. So node A performs two separate calls to |
|
In that case, you'll want to create some synthetic |
|
Is there a way to provide a list of I guess the latter could work but it would add a lot of complexity outside of LDK - potentially calling the router multiple times to construct routes to each of our peers and then adding the last hop. |
|
Oops, somehow I missed this. The last hops are provided under the |
|
I assume you're building the |
|
Thanks for the tip, this worked perfectly for payments where the two nodes have direct channels together, but we are still seeing failures in test cases where multiple hops are required to complete the payment. It's effectively the same issue, but happening on the channels "in the middle" of the path, which causes them not to be announced. For us this is not a deal breaker right now, I just wanted to point it out for the sake of completeness. |
|
FWIW, this might be connected to the failing test cases I'm seeing in lightningdevkit/ldk-node#157. Will investigate that further. |
|
Are both issues fixed with a sleep? Shouldn't be too hard to poll and just wait until gossip has finished in that case. If not, are you using a |
I had also suspected that but even a sleep of 60 seconds doesn't do the trick unfortunately. Have yet to look closer into the logs and check how announcements/updates are propagated and if some are never reaching the sending node. |
|
Turns out the behavior I was seeing on LDK Node had nothing to do with gossip propagation, but everything with the fact that I tried to pay an amount under |
|
From my testing our issue isn't fixed just by waiting, because after the two nodes try and fail to announce the channel (because one of them isn't ready yet) they don't try to do it again until we restart the node. Or in general I think what you need is to disconnect and reconnect to the peer so that they both realize the public channel isn't announced yet and they do it then, which is achieved by restarting. It's not a big issue for us, but I think technically this is still a bug in LDK, how do you feel about re-opening this just as a reminder? |
That seems like a bug. We should be reliably waiting until the channel is ready on both sides before either side tries to broadcast. Are you maybe hitting #2418? If not, lets open a new issue to track this. |
|
I'm not sure, maybe it could be the same issue but I'm not very familiar with the internals of LDK: in our case it looks like the channel is never announced at all (so at first I wouldn't think about a re-broadcasting issue), but looking at the logs the line seems to imply that the problem is not directly related to the generation of the channel announcement, it happens when handling a |
|
Hmm, I'd be surprised if the channel_announcement were getting rebroadcasted on reconnection in recent-ish LDK unless it made it into the |
|
Sorry for the delay, I've spent some time trying to figure it out myself but I couldn't really get anywhere. Here are the logs for the two nodes: Node 1Node 2 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Opening this issue after this (brief) conversation on discord: https://discord.com/channels/915026692102316113/978829624635195422/1138151233920700436
Essentially i've been working on a fork of LDK that adds support for RGB assets.
We have been seeing an intermittent issue which i believe it could be caused by some race condition in LDK itself: specifically, if we receive a channel update from our peer before the channel is added to the network graph (this happens in like 5-10% of the cases when said peer is opening a channel with us) we end up with a channel entry in the network graph that's missing one of the two directions, which means it can't be used to route payments in that direction obviously.
What i mean with that is that our channel info struct ends up having only
two_to_oneset toSome(_), whileone_to_tworemainsNoneand is unusable by the router:Here's the relevant part of the logs:
The text was updated successfully, but these errors were encountered: