You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
, we can see that if there is an error while making the request, the code returns and therefore no trace logging happens. This is unexpected behavior and makes things hard to debug. Even if the response doesn't come, the tracing logs both request and response. So it's always expected to log the request regardless of the response.
I'd suggest to split the method into 2 parts: first logging the request unconditionally, then logging the response along with the condition of && resp.StatusCode == http.StatusOK.
we only print when the "request" was actually sent and we did get a "Response" back.
Yes, that is the problem here. Due to this, the user does not know exactly which requests are failing which makes things hard to debug. I'd suggest to log the request unconditionally, and then log the response with the same logic as you are doing now.
Currently, it's not implemented to print tracing for network errors. The main reason is we use Go's httputil to print the relevant trace format.
You just need to display the request using httputil.DumpRequestOut.
In this line
minio-go/api.go
Line 491 in ff482a1
I'd suggest to split the method into 2 parts: first logging the request unconditionally, then logging the response along with the condition of
&& resp.StatusCode == http.StatusOK
.Due to this, we are unable to debug connection failures from object storage: mattermost/mattermost#19584
The text was updated successfully, but these errors were encountered: