Skip to content

Conversation

@tnull
Copy link
Collaborator

@tnull tnull commented Nov 25, 2025

Second, more thorough attempt:

Previously, we could in tests potentially run into listening port collisions resulting into InvalidSocketAddress errors. These errors could surface if we rolled port numbers that either collided with other concurrent tests or with other unrelated services running on localhost.

Here, we simply let the OS assign us a free port number when setting up the testing nodes, which avoids such collisions altoghether (mod the potential TOCTOU race here, which we ignore for now).

@tnull tnull requested a review from joostjager November 25, 2025 09:59
@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Nov 25, 2025

👋 Thanks for assigning @joostjager as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@tnull tnull force-pushed the 2025-11-avoid-port-collisions branch from da47569 to bfda813 Compare November 25, 2025 10:06
@tnull
Copy link
Collaborator Author

tnull commented Nov 25, 2025

Hmm, even with the current changes I didn't get much insight into the ConnectionFailed flakes. Will close this for now and will reopen once I do. Excuse the noise, @joostjager.

@tnull tnull closed this Nov 25, 2025
@tnull tnull reopened this Nov 25, 2025
@tnull tnull force-pushed the 2025-11-avoid-port-collisions branch from bfda813 to 1b7d919 Compare November 25, 2025 12:43
@tnull
Copy link
Collaborator Author

tnull commented Nov 25, 2025

Now reopened instead of #719.

joostjager
joostjager previously approved these changes Nov 25, 2025
Copy link
Contributor

@joostjager joostjager left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing blocking


for _ in 0..num_addresses {
let rand_port = random_port();
while listening_addresses.len() < num_addresses {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the former for loop can remain?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I'm not sure that there is a guarantee that we don't get the same port back if we drop socket each iteration. I guess we could push them to a Vec to keep them alive while we're still iterating, but this seemed easier.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm although obvious, I didn't realize that we don't actually use the socket. In that case, it definitely seems better to keep the sockets alive?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm although obvious, I didn't realize that we don't actually use the socket. In that case, it definitely seems better to keep the sockets alive?

No, why? We def. don't want to keep it alive to allow the Node setup a new one?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean during the iteration, for the reason you brought up?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, but the OS likely gives back random available ports, and we dedup via the HashSet, so we're good?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Idk if that is always the case for all OSes? Seems there is endless loop potential here. It's just test, fine to leave as is, but it doesn't feel 100% solid.

Previously, we could in tests potentially run into listening port
collisions resulting into `InvalidSocketAddress` errors. These errors
could surface if we rolled port numbers that either collided with other
concurrent tests *or* with other unrelated services running on
localhost.

Here, we simply let the OS assign us a free port number when setting up
the testing nodes, which avoids such collisions altoghether (mod the
potential TOCTOU race here, which we ignore for now).

for _ in 0..num_addresses {
let rand_port = random_port();
while listening_addresses.len() < num_addresses {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Idk if that is always the case for all OSes? Seems there is endless loop potential here. It's just test, fine to leave as is, but it doesn't feel 100% solid.

@tnull tnull merged commit b4b2843 into lightningdevkit:main Nov 26, 2025
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants