Skip to content
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

Object is not traced when the request returns an error #1664

Open
agnivade opened this issue Jun 13, 2022 · 2 comments
Open

Object is not traced when the request returns an error #1664

agnivade opened this issue Jun 13, 2022 · 2 comments
Assignees

Comments

@agnivade
Copy link

In this line

minio-go/api.go

Line 491 in ff482a1

if err != nil {
, 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.

Due to this, we are unable to debug connection failures from object storage: mattermost/mattermost#19584

@harshavardhana
Copy link
Member

In this line

minio-go/api.go

Line 491 in ff482a1

if err != nil {

The error will be displayed at the end @agnivade - we only print when the "request" was actually sent and we did get a "Response" back.

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.

Let's see if we can add this to the trace.

@harshavardhana harshavardhana self-assigned this Jun 13, 2022
@agnivade
Copy link
Author

Thanks @harshavardhana

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.

@bh4t bh4t added the community label Feb 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants