-
Notifications
You must be signed in to change notification settings - Fork 980
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
Inconsistent response attribute for Faraday::RetriableResponse raised on Retry loop #956
Comments
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 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
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:
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.
The text was updated successfully, but these errors were encountered: