-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
E2E integration tests are flaky #25423
Comments
One option would be to forego running the actual binary by spawning the influxdb/influxdb3/src/commands/serve.rs Line 320 in 7d37bbb
This would require some refactoring to make sure that the test harness is starting things exactly as is done for the actual running binary, but would allow us to pass in a bound One problem I see with this is that, with the way we generate IDs for, e.g., databases and tables, using |
Another option would be to have the binary log the port it is listening on, and scrape if from the STDOUT in the test harness code. |
Another option would be to have an option in the |
I think I like the log option |
There might be one more option to use unix sockets ( |
From time to time, some of the integration tests fail for strange reasons. It may be due to how a port is being selected for the running
influxdb3 serve
binary that is spun up in the test harness.There is a function used to select a random available port:
influxdb/influxdb3/tests/server/main.rs
Lines 305 to 319 in 7d37bbb
However, since the bind address is dropped before it is passed in to spawn the server (it needs to be, otherwise the server would not be able to bind that address and would fail to start), then there is a chance that another process or integration test could take over that port before the binary is started here:
influxdb/influxdb3/tests/server/main.rs
Line 136 in 7d37bbb
Here are some examples of failures that seem rather odd:
The text was updated successfully, but these errors were encountered: