Errors from original http.Client response are double-wrapped when using the RoundTripper #95
Conversation
|
|
d82c5cd
to
0e0b489
Compare
|
cc @jefferai - Just wanted to ping a maintainer for some 👀 here. |
|
cc @ryanuber - in case you are able to help here :) Ah, just realized your wrote the RoundTripper here, so probably perfect for you. |
|
@andrewlouis93 at the moment no reviews can proceed since you have not signed the CLA. |
…ng the custom RoundTripper only proceed with the unwrapped error if it can be unwapped normalize error
0e0b489
to
030fba5
Compare
|
@jefferai Done, had committed this with a different email attached |
|
I think this looks good -- do you know if this is only an issue with |
|
@jefferai That's a good consideration. In this case yes, but only because We can be a bit more strict here and only unwrap if the error is an Just updated and left some comments, take a look and let me know what you think. |
7315ade
to
0b5a47c
Compare
|
LGTM, thanks! |
When you're using a
http.Clientwith a customRoundTripperthat actually facilitates the retries (it maintains its own internalhttp.Clientobject); any errors returned from the originalhttp.Clientare re-wrapped.For instance, trying to do a Get request that returns an error response, and using the PassthroughErrorHandler to return the real failure would result in an error like this:
This is basically an
*url.Errorobject nested within another*url.Error'sErrfield.We can just
.Unwrap()it to make sure that we only get what we need. Open to other suggestions though.