Open bpo opened 4 years ago
@bpo merged a change in: https://github.com/intercom/intercom-ruby/pull/548
That should reveal more of our verbose error messages
Reopening issue as we had to revert https://github.com/intercom/intercom-ruby/pull/548
Intercom's API may reply with a response that looks like this:
{"type"=>"error.list", "request_id"=>"xxxxx", "errors"=>[{"code"=>"action_forbidden", "message"=>"An email to this user has hard bounced and they cannot be messaged via email"}]}
As noted above this will raise an Intercom::AuthenticationError
with no information other than the message "Forbidden".
With the patch from #548 applied the raised error will instead be:
Intercom::UnexpectedError (The error of type '' is not recognized. It occurred with the message: An email to this user has hard bounced and they cannot be messaged via email and http_code: '403'. Please contact Intercom with these details.)
This is caused by two separate issues not addressed in #548:
action_forbidden
is not supported in this clientmessage_for_unexpected_error_with_type
) expects errors to have a type
field where the current API uses a code
field.The workaround for a codebase I maintain was to refine the behaviors of raise_errors_on_failure
and raise_application_errors_on_failure
pending support for this gem from Intercom.
This still seems to be happening.
Version info
Expected behavior
Exception objects raised by the Intercom client should include the error message, as are surfaced by the API. For example, this is a possible API response body associated with a 403 Forbidden response code. The message is very important to understanding why the action is forbidden:
Actual behavior
The Ruby client masks all details of the error returned by the API, and surfaces only a blank Ruby object that can be used to guess the return code, but not the message:
Steps to reproduce
Additional details
It looks like the client was designed to parse these error messages properly in raise_application_errors_on_failure, but most non-20x response codes will abort client handling early in raise_errors_on_failure