Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add listen_tcp_on_free_port to return a test port #41

Merged
merged 3 commits into from
Dec 31, 2024

Conversation

DanGould
Copy link
Collaborator

@DanGould DanGould commented Dec 30, 2024

Previously in tests downstream ohttp_relay was initiated with a port
that may no longer be free by the time it got bound. By having this
code bind on and return the port the indirection is removed.

I also found that the way I was having NGINX listen on a free port may also have led to the same problem, so the 3rd commit ensures NGINX is bound before the ohttp_relay tries to get a free port.

Reduce a bunch of duplicated boilerplate code
Previously in tests downstream ohttp_relay was initiated with a port
that may no longer be free by the time it got bound. By having this
code bind on and return the port the indirection is removed.
NGINX was also returning before binding to the port, sometimes leading to
port contention with other test services

Fix by waiting for it to connect before attempting to start other services
Copy link

@nothingmuch nothingmuch left a comment

Choose a reason for hiding this comment

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

not sure about the last commit, i'd prefer if start_nginx returned a Result<NginxProcess>, but i think it's fine to merge this so that listen_tcp_on_free_port is exposed and followup with a refactor, since the new behavior is still an improvement on the old

Comment on lines +459 to +464
while start.elapsed() < timeout {
if let Ok(_) = std::net::TcpStream::connect(format!("127.0.0.1:{}", n_https_port)) {
break;
}
tokio::time::sleep(std::time::Duration::from_millis(100)).await;
}

Choose a reason for hiding this comment

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

happy path and error path are not distinguished, which is strange to me... if the timeout elapses and nginx was not yet listening, why proceed?

@DanGould DanGould force-pushed the return-port branch 2 times, most recently from e04c6ce to d8f7578 Compare December 31, 2024 03:10
@DanGould
Copy link
Collaborator Author

I accidentally pushed the fix here but will open it in a new PR. that was a brain fart, obviously we want to separate the paths and return an error if we fail.

I'm going to merge the approved commit to enable forward motion

@DanGould DanGould merged commit d3f853f into payjoin:main Dec 31, 2024
10 checks passed
@DanGould DanGould deleted the return-port branch December 31, 2024 03:18
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.

2 participants