Thanks, @dentiny. We log errors while reading the response body, but we don’t really care about errors that occur when closing the body. Do you have any experience suggesting that they can be helpful?

Thanks, @dentiny. We log errors while reading the response body, but we don’t really care about errors that occur when closing the body. Do you have any experience suggesting that they can be helpful?

My general practice is don't ignore error in all cases; logging, propagation, crash are all strictly better than ignore.
In this particular case, we read from response body and discard; if the read operation fails somehow, connection cannot be reused and could lead to unexpected performance degradation.

if the read operation fails somehow, connection cannot be reused and could lead to unexpected performance degradation.

And how can that log be helpful in this case?

And how can that log be helpful in this case?

According to the USE method, error logging is one of the items we need to check first. The logging here helps people understand what was going wrong in the system.

According to the USE method, error logging is one of the items we need to check first.

It doesn't talk about application logs, but instead talk about metrics provided by the operation system. Those metrics are indeed a better source for monitoring TCP efficiency, including reconnections.

The logging here helps people understand what was going wrong in the system.

Aren't the error logs while reading the response body enough? Here: