-
Notifications
You must be signed in to change notification settings - Fork 270
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
tests (simple_server.py) still unreliable #1111
Comments
Possible workaround: add a
This does not fix the underlying issue (whatever it is) but I think it would effectively workaround it: I've never seen a case where two server startups failed in a row so retrying should alleviate the issue |
Chatted with Martin, current plan is:
|
More details from https://travis-ci.org/github/theupdateframework/tuf/jobs/718988503 (this one happens to print server output):
So it seems to be the child process getting EADDRINUSE! (can't be 100% sure before #1104 is fixed because we don't know for sure which test the simple_server.py output is from. We also don't know if this is happening in all error cases as the output is not collected everywhere) . Will have to think if there's a better way to solve this but the workaround I proposed should definitely work. |
There is another case to take into account:
The only way to solve this case reliably is that the code starting the server process must get a message from the server process that says "bind succeeded". The simple way to do this would be
|
I was hoping the unreliability would mostly disappear with #1096 but this does not seem to be the case:
Based on the timing info above my hypothesis is that the server startup is not actually that slow: it's just that sometimes it's not going to happen at all. Could it be that there is/was something running on the chosen port already, and for some reason we don't get EADDRINUSE but end up waiting for a long time?
The text was updated successfully, but these errors were encountered: