Uninitialized constant Faraday::Error::ClientError

[Sprachprofi]

Uninitialized constant Faraday::Error::ClientError

[amro]

Thanks @Sprachprofi. This seems like a bug — Gibbon should throw a proper error with whatever response the API provides. Unfortunately, I am traveling for work the next week and I don’t expect I’ll have time to investigate this in the meantime. I can investigate once I get back from my trip (next weekend), or I’m happy to accept a patch if you are interested in taking a look (no expectation of that on my end, to be clear).

The expected behavior is to throw a gibbon typed error that wraps whatever the API returns, but I do not want to define an error type/class for every API error.

Taking a quick look at the source, I suspect the bug is on line 114 of api_request.rb

gibbon/lib/gibbon/api_request.rb

Line 114 in 5ce47aa

client_error = error.is_a?(Faraday::ClientError) || error.is_a?(Faraday::Error::ClientError)

[Sprachprofi]

Hey, thanks for the quick response. That does look like it. Fwiw, I upgraded to the latest version of Gibbon and that fixed it, so there may not be a need to do anything. People who will continue to be affected are those forced to use Gibbon 3.2.x, for example because of being locked into an earlier Ruby version. Those would need to figure out which is the last version of Faraday that still uses Faraday::Error::ClientError rather than the newer Faraday::ClientError and then manually lock to that one, because Gibbon 3.2.x does not have an upper bound on Faraday version.

[amro]

I see. Then this was already fixed. Thank for clarifying. I don’t know if one can retroactively change version requirements for a gem. Glad you’re able to move forward though. I’ll think on how to avoid this sort of thing in the future.

…

On Jan 13, 2020, at 1:52 AM, Judith Meyer ***@***.***> wrote:  Hey, thanks for the quick response. That does look like it. Fwiw, I upgraded to the latest version of Gibbon and that fixed it, so there may not be a need to do anything. People who will continue to be affected are those forced to use Gibbon 3.2.x, for example because of being locked into an earlier Ruby version. Those would need to figure out which is the last version of Faraday that still uses Faraday::Error::ClientError rather than the newer Faraday::ClientError and then manually lock to that one, because Gibbon 3.2.x does not have an upper bound on Faraday version. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.