isahc: failed to write response body because the response reader was dropped
When doing a lot of very similar requests, occasionally i will get logs like this:
[WARN] failed to write response body because the response reader was dropped
I know these are just warnings, but I’m currently debugging a tricky problem and I’d rather be sure about what is happening. Why are these warnings happening, and is there any way to prevent them?
Here’s the code in question:
let response = isahc::http::Request::put(format!("{}/links/_bulk", opt.elastic_url))
.header(CONTENT_TYPE, "application/json")
.authentication(Authentication::basic())
.credentials(Credentials::new("elastic", opt.elastic_pass.clone()))
.body(body.to_string())?
.send()?;
if !response.status().is_success() {
let mut buffer = String::new();
response.into_body().read_to_string(&mut buffer)?;
error!("Got non-success status code, response was\n {}", buffer);
}
Is this perhaps due to into_body consuming the response?
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 15 (9 by maintainers)
Commits related to this issue
- Fix abort warning and add explicit abort method Previously we were using two different atomic sources to discover when a response has been dropped, but only emitting a warning for an unconsumed respo... — committed to sagebind/isahc by sagebind 4 years ago
- Fix response body abort warning Previously we were using two different atomic sources to discover when a response has been dropped, but only emitting a warning for an unconsumed response body if one ... — committed to sagebind/isahc by sagebind 4 years ago
- Fix response body abort warning (#280) Previously we were using two different atomic sources to discover when a response has been dropped, but only emitting a warning for an unconsumed response body ... — committed to sagebind/isahc by sagebind 4 years ago
I decided to change this log to an
INFOlevel message instead and to make the message itself much more understandable (as well as fix the message being reported inconsistently). This change will be in the next release.Yep, that’s right, this is only a problem when making multiple requests to the same server. By default we cache everything for a short time since Isahc doesn’t know if you are going to make more requests to the same server or not, though this can be changed with custom client configuration.
Thanks for all the helpful information! I’ll be digging deeper into this issue soon to see what I can find out.