Closed Alan-M-Thomaz closed 3 years ago
I agree wholeheartedly that this inconsistency is a problem. I would like to move away from wide open hashes, towards objects with documented attributes. Ideally, our users should avoid code like that case
statement in your example, and Faraday should not make that necessary.
We're currently in a push to release Faraday v1 (#903), so we can't simply fix this by returning a Response object in RaiseError. I would be open to some helpers like #response_status
though. After a quick glance at Faraday::Response
, I think at least we'd want the following:
I've made a note of this on my Faraday v2 wishlist (#953) to fix properly.
For those stuck on Faraday v1, this may be useful:
case response
when Hash
# Sometimes response is a hash, and other times it is a response object.
# Downstream from here it is expected to always be a response object.
# See: https://github.com/lostisland/faraday/issues/956#issuecomment-478072433
Faraday::Response.new(response.transform_keys({headers: :response_headers}))
else
response
end
It rebuilds the response object from the Hash.
Basic Info
Issue description
The response on the exception Faraday::RetriableResponse raised by retry loop is a instance of Faraday::Response, while errors raised by the middleware RaiseError are simple hash.
that is kinda bad for checking body, headers, and status, because in one they are attributes, and in the other they are keys
Steps to reproduce
Using webmock , and rspec. i removed some unnecessary code, you probably can also use just faraday stubs instead of webmock.