Failing request results in a misleading empty success response from sidekick

[gbdolberg]

A request that fails during go's reverse proxy ServeHTTP results in a basically empty response with a 200 status code.
To me it seems very misleading because boto f.e. ends up excepting when it can't find the headers it expects a successful response to have.

Expected Behavior

I would think in case of an errorours request the response would be attached with a status code that reflects an issue.
Like go's defaultErrorHandler does by writing http.StatusBadGateway.

Current Behavior

SideKick's Backend's custom ErrorHandler only logs and sets the backend as offline, without changing the response.
So when the http tracer finishes with f(rw, r) it continues the same regardless of if the request was successful or not, and just relies on its custom ResponseWriter's default StatusCode: http.StatusOK,.
So the end result is an empty response in my case (with just 'Server' : 'SideKick' as a single header) and a 200 return code.

Possible Solution

I think the custom ErrorHandler should do what defaultErrorHandler and apply http.StatusBadGateway to the response.
Or change ResponseWriter's default status code to that.

Steps to Reproduce (for bugs)

Actually not sure, don't really understand yet why in my env the http requests even fail ("OpError" that just says "tcp"), as a result of transport.RoundTrip(outreq).
But I would assume that causing that RoundTrip to fail somehow would reproduce this.

Context

For some reason sometimes when sidekick sends requests to my env ServeHTTP fails, and instead of reflecting that something went wrong sidekick returns a 200 response. Causing my boto to except when it can't find an ETag in the response headers.

Your Environment

• Version used (sidekick version): Custom build of a clone of the master branch (dce1854).
• Operating System and version (uname -a): amazon linux 2

[harshavardhana]

Please provide a reproducer @gbdolberg - thank you

[harshavardhana]

No valid reproducer provided closing