Adapter#ajax#catch doesn't give access to the server's response

[shellandbull]

Hello guys,

I have a custom request that I want to send using the adapter. Looks something like this

adapter
  .ajax(adapter.buildURL('/change_password').singularize(), 'POST', options)
  .catch(handleFailure);

My server will reply with 422 and a payload with errors. When it does handleFailure will be called however, the only argument yield into it is an $adapters$errors$$InvalidError Which doesn't provide an interface to see the payload :( is there any other way of accessing it?

[KTKate]

if I go into that $adapters$errors$$InvalidErrorI can reach the payload errors. It's like errors[0].detail. off the top of my head. Console.log (handleFailure) and poke around in there. Other than doing that though I also don't seem to be able to get my errors in a more straight forward way.

[shellandbull]

@JKGisMe that's a really weird interface to access errors. It provides no means of mapping back to a user interaction or a resource in the client. Consider the following

Attempting to save a model, i.e: a user that is invalid

1 - Server responds with 422 and the following payload

{ errors: { phone: ['invalid'] } }

2 - On the client, my user becomes invalid and its DS.Errors is properly populated with the errors. I can leverage that API to display errors to the client

Attempting a validatable custom action

1 - Server responds with 422 and the following payload

{ errors: { phone: ['invalid'] } }

2 - Even though I have an entity with a DS.Errors and a phone attribute(Like a component in which this.errors is an instance of DS.Errors) I don't have an interface to manually set them

Conclusion errors[0].detail is just not good enough nor it resembles the behaviour of the original interface that ember-data provides for a 422 :)

I wouldn't mind implementing the functionality if that's the issue. Something as simple as $adapters$errors$$InvalidError#payload would be heaven for a lot of people.

[KTKate]

Don't get me wrong, I'm not saying that it's ideal. More like a workaround if you really needed to find the errors. I can't even get my models' errors any other way. Apparently something in my relatively vanilla setup confuses ED.

[shellandbull]

@JKGisMe that's no worries. That's the workaround I initially implemented. But I believe it really shouldn't be like that, #then #catch and #finally should give you access to at least the payload and status code

[pangratz]

@mariogintili sorry for the long overdue response 😔 ember-data creates custom error objects based on the response: InvalidError for 422 and AdapterError for other responses which are not a success or invalid (see RESTAdapter#handleResponse). There is also the ds-extended-errors feature added in #3586 and #4287, which adds more errors (like forbidden and not found).

These custom errors encapsulate all the information of the error, so checking if the thrown error is an instanceof DS.InvalidError, the specific status isn't necessary. Also the errors in the payload are "translated" so the original payload shouldn't be needed anymore. That's the reasoning for the specific errors not having the status and payload on them. Makes sense?

If you need in your case the status and the payload because you do some custom logic with them, you can override DS.RESTAdapter#handleResponse and return an instance of DS.AdapterError (or DS.InvalidError, ...) and set the status and payload on them.

Does that help?

[shellandbull]

thanks for getting back @pangratz 🎯

[joelpresence]

How do you enable the extended errors? Setting ds-extended-errors in config/environment.js in ember-cli 2.9.1 has no effect ...

[pangratz]

@joelalejandro the ds-extended-errors feature is enabled by default since 2.13. Also see the accompanying blog post.