If I make a retryable HTTP request with a context, and I cancel that context before the request is complete, this library will log that at the ERROR log level. The resulting log looks something like:
However, there are legitimate reasons to want to cancel the context and any pending HTTP requests as part of "normal operation". For example, if I'm making this HTTP request in response to a different HTTP request I received, and that different request was cancelled, I would want to cancel this HTTP request since it's no longer needed. In such a case, the fact that this request gets cancelled should not be considered an "error".
It would be quite helpful for log hygiene if the code could do an errors.Is(err, context.Cancel) check and, if it returns true, log this at a DEBUG or INFO level instead of at the ERROR level.
If I make a retryable HTTP request with a context, and I cancel that context before the request is complete, this library will log that at the
ERRORlog level. The resulting log looks something like:However, there are legitimate reasons to want to cancel the context and any pending HTTP requests as part of "normal operation". For example, if I'm making this HTTP request in response to a different HTTP request I received, and that different request was cancelled, I would want to cancel this HTTP request since it's no longer needed. In such a case, the fact that this request gets cancelled should not be considered an "error".
It would be quite helpful for log hygiene if the code could do an
errors.Is(err, context.Cancel)check and, if it returns true, log this at aDEBUGorINFOlevel instead of at theERRORlevel.