-
Notifications
You must be signed in to change notification settings - Fork 25.4k
Extend HTTP timeout in repo analysis tests #131744
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
Extend HTTP timeout in repo analysis tests #131744
Conversation
We set a 120s timeout on the repo analysis that runs in these tests, but the REST client in use has a read timeout of 60s so any analysis that lasts longer than that will yield an HTTP timeout that contains very limited information to help further investigation. With this commit we extend the HTTP timeout to be a few seconds longer than the analysis timeout so we should get a proper response in these cases.
Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
request.addParameter("seed", Long.toString(randomLong())); | ||
request.setOptions( | ||
RequestOptions.DEFAULT.toBuilder() | ||
.setRequestConfig(RequestConfig.custom().setSocketTimeout(Math.toIntExact(timeout.millis() + 10_000)).build()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.setRequestConfig(RequestConfig.custom().setSocketTimeout(Math.toIntExact(timeout.millis() + 10_000)).build()) | |
.setRequestConfig(RequestConfig.custom().setSocketTimeout(Math.toIntExact(timeout.seconds() + 10)).build()) |
You have seconds above and milliseconds here. We're probably more accustomed to thinking in milliseconds, so leaving it as-is is fine with me, too 🤷♀️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the parameter to setSocketTimeout
is a raw integer representing the timeout in milliseconds - we could add ten seconds like this but then we'd have to convert it to millis either by multiplying by another magic number or else converting it back to a TimeValue
and back again
We set a 120s timeout on the repo analysis that runs in these tests, but the REST client in use has a read timeout of 60s so any analysis that lasts longer than that will yield an HTTP timeout that contains very limited information to help further investigation. With this commit we extend the HTTP timeout to be a few seconds longer than the analysis timeout so we should get a proper response in these cases.
We set a 120s timeout on the repo analysis that runs in these tests, but the REST client in use has a read timeout of 60s so any analysis that lasts longer than that will yield an HTTP timeout that contains very limited information to help further investigation. With this commit we extend the HTTP timeout to be a few seconds longer than the analysis timeout so we should get a proper response in these cases.
💔 Backport failed
You can use sqren/backport to manually backport by running |
We set a 120s timeout on the repo analysis that runs in these tests, but the REST client in use has a read timeout of 60s so any analysis that lasts longer than that will yield an HTTP timeout that contains very limited information to help further investigation. With this commit we extend the HTTP timeout to be a few seconds longer than the analysis timeout so we should get a proper response in these cases. Backport of elastic#131744 to 9.0
We set a 120s timeout on the repo analysis that runs in these tests, but the REST client in use has a read timeout of 60s so any analysis that lasts longer than that will yield an HTTP timeout that contains very limited information to help further investigation. With this commit we extend the HTTP timeout to be a few seconds longer than the analysis timeout so we should get a proper response in these cases. Backport of elastic#131744 to 8.18
We set a 120s timeout on the repo analysis that runs in these tests, but the REST client in use has a read timeout of 60s so any analysis that lasts longer than that will yield an HTTP timeout that contains very limited information to help further investigation. With this commit we extend the HTTP timeout to be a few seconds longer than the analysis timeout so we should get a proper response in these cases. Backport of #131744 to 8.18
We set a 120s timeout on the repo analysis that runs in these tests, but the REST client in use has a read timeout of 60s so any analysis that lasts longer than that will yield an HTTP timeout that contains very limited information to help further investigation. With this commit we extend the HTTP timeout to be a few seconds longer than the analysis timeout so we should get a proper response in these cases. Backport of #131744 to 9.0
We set a 120s timeout on the repo analysis that runs in these tests, but
the REST client in use has a read timeout of 60s so any analysis that
lasts longer than that will yield an HTTP timeout that contains very
limited information to help further investigation. With this commit we
extend the HTTP timeout to be a few seconds longer than the analysis
timeout so we should get a proper response in these cases.