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

Flaky connections_and_errors:request_timeout_microsecond test #1052

Closed
rkubes opened this issue Mar 3, 2019 · 1 comment · Fixed by #1097
Closed

Flaky connections_and_errors:request_timeout_microsecond test #1052

rkubes opened this issue Mar 3, 2019 · 1 comment · Fixed by #1097

Comments

@rkubes
Copy link
Contributor

rkubes commented Mar 3, 2019

The connections_and_errors:request_timeout_microsecond is failing intermittently.

I'm using commit: 91f66c6 (v2.10.10)

If I loop the test 1000 times, it fails anywhere from 5% to 17% of the time on a Raspberry Pi2, and 0% to 0.7% of the time in an Ubuntu VM.

In the meantime, is it possible for me (on my local repo) to somehow mark this test to be ignored? I have a script that won't build the install package if any of the tests fail.

@rkubes
Copy link
Contributor Author

rkubes commented Apr 2, 2019

I at least narrowed down why it fails erroneously. In http_client_asio.cpp, eventually the "handle_connect" is called. During (or maybe after) the handle_connect call, it's expected to throw an exception for timing out (std::errc::timed_out).
However, if the timeout occurs before the "handle_connect" function is called, then the error_code passed to it is already set to: boost::asio::error::operation_aborted; and thus "Request canceled by user." is thrown instead.
Essentially, what I believe is happening is the 500 microseconds that's coded into the test is enough time, most of the time, for the test to be valid. However, there are cases (high load, or slow CPU) where the http_client "times out" before the point where it would thrown the expected exception.

One can easily replicate this by adding a "sleep" to the "handle_resolve" function, and then play with the hard coded timeout value in "connections_and_errors.cpp" - if the timeout in connections_and_errors is greater than the sleep time added to handle_resolve, the tests will pass. If the timeout is shorter than the sleep time, then they will fail every time due to the operation_aborted exception being thrown.

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 a pull request may close this issue.

1 participant