Behaviour for resource with both transformResponse and interceptors

[ZNS]

I have a $resource with both transformResponse and an interceptor. The transformResponse deserializes the response from json and then modifies it. The interceptor handles responseError. The problem is when the request throws http error 500 the transformresponse is called (where the status of the request is not available) it tries to deserialize json and fails. In the interceptor responseError method I now get an object that has a property "message" with "Json.Parse error". I am unable to catch the http 500 error anywhere.

[pkozlowski-opensource]

@ZNS I think we've got already a similar issue for this. To confirm, could you please prepare a plunk with a minimal reproduce scenario?

[ZNS]

Here it is. As you can see in responseError for the interceptor we don't get access to the request status or config, just a message. It is also not possible to figure out the http exception from the transformResponse method.
http://plnkr.co/edit/8M7LqOxZGaegjjzKnVqG?p=info

[caitp]

This is how promises work, @ZNS --- you have your promise handler, it throws, the chained promise is rejected with the exception that was thrown.

This is pretty much working as expected, so I'm not sure we want to do much about this. The weird thing to me, is that $resource is transforming your 404 response at all.

[ZNS]

@caitp The issue is that if I use transformResponse the http exception is not caught in the interceptors responseError. Hence the only way to find out if an http exception was thrown is to parse the html output (if any) in transformResponse. This can't be how it's meant to be.

I don't see why transformResponse is called at all if there was an http exception (status != 200). I'd prefer that responseError on the interceptor caught the http exception.

[caitp]

I understand your issue.

This is how it's meant to be, because response interceptors happen after transformation occurs --- this allows them to catch errors during transformation.

It might be sensible to include an HTTP status in the transform functions, though.

[ZNS]

Ok. What I want to do is to retry a request if there's an http exception. But that will not be possible if I attach transformResponse then? Because I can't find out if there was an http exception and even if I get the http status back I won't get the http config of the request to retry it?

By the way I think this is the similar issue for this:
#7594

[caitp]

I don't think it makes sense to send the config object to the transform function. but it may make sense to send the response object, or just the status code

[ZNS]

As a workaround I guess I could skip transformResponse and use the response method on the interceptor instead. Since I'm only interested in manipulating the parsed json. However since I'm using ngResource I am attaching transformResponse only to certain resources. But I guess I can create multiple interceptors to get around that.

Anyway I think it'd be great to be able to handle http exceptions even when using tranformResponse.

[gkalpak]

An idea would be to follow the interceptors "paradigm" for transformers as well, i.e. having transformRequest, transformRequestError, transformResponse and transformResponseError.
But it is might be too big of a change for the value it adds.

Passing the status to the response transformer seems reasonable though (and is probably "good enough").

[pkozlowski-opensource]

Yes, I think we had a request to include response status so transformers can inspect it.