No error details given when response is an HTTP 422

[pirj]

client.domain.create('my_app', {hostname: "mydomain.com"})
Excon::Error::UnprocessableEntity: Expected([200, 201, 202, 204, 206, 304]) <=> Actual(422 Unprocessable Entity)

with curl:

curl -v -n -X POST https://api.heroku.com/apps/$MY_APP/domains -d '{ "hostname": "mydomain.com" }' -H "Content-Type: application/json" -H "Authorization: Bearer $HEROKU_API_TOKEN"
...
< HTTP/1.1 422 status code 422
...
{
  "id":"invalid_params",
  "message":"mydomain.com is currently in use by another app."
}

[jeffects]

Yeah, it is unfortunate that the error message isn't being passed but in the meantime, I believe you can retrieve the error message by parsing the response.

begin
  client.domain.create('my_app', {hostname: "mydomain.com"})
rescue Excon::Error::UnprocessableEntity => e
  JSON.parse(e.response.data[:body])
end

Hope that helps!

[pirj]

Oh, didn't know response is wrapped into exception. That works around the issue, thanks!
Should I leave the ticket open until there's a better option to get the error message.

[geemus]

Yeah, if you leave it open I can see about improving the default messaging. Sorry for the difficulties here, but glad you have a reasonable workaround available.

[djcp]

@geemus There are 2 places I could see making this improvement:

1. in heroics, possibly by rescuing some subset of excon errors and re-raising a heroics specific-error instance, and
2. In excon, though that seems to be so widely used that I'd be loath to modify how it throws errors.

Thoughts? Other ideas?

[geemus]

Yeah, I was thinking heroics would probably be the right level/place for it.

[fschwahn]

It might be a good idea to add such an error response to the example in the README. I wanted to know what happens in case of an error (ie. if an error is raised, or if I have to look at the return value of eg. heroku.dyno.create), and this is not addressed.