Ember Data Mixin Breaks Adapter Level Error Handling

[jherdman]

In investigating how our Ember Data mixin works with a few of our apps at Precision Nutrition, I noticed that adapter level error handling is circumvented. This breaks applications by changing the expected shape of API errors.

[XaserAcheron]

I'm a bit stumped on how best to actually implement a test for this. The acceptance test that exists for testing the ember-data integration doesn't allow (non-hacky) access to the actual model object, and I haven't quite figured out how to import everything necessary to make ED's store work in an integration test. Welp!

Ideally I'd like to be able to call store.findRecord directly and inspect the contents after success/failure to make sure everything's kosher, but that's an unusually difficult nut to crack. Anyone have any insight, by chance?

[jherdman]

I suppose we could set up an acceptance test scenario wherein a model has an active-model-adapter, and we look to see that the output from an error request aligns with what we expect.

[sumeetattree]

Not sure if this is related but I ran into a situation where the handleResponse of the underlying DS.JSONAPIAdaptor is being overriden and super is not called. It is causing problems with ember-simple-auth that relies on the adapter's handleResponse to detect whether a request failed with 401.

Is there a work around while some work is being done on this?