Issue with canceling XHR request using promises - fixed #12525

[netman92]

Fixes #10890 and #9332.

@jtheoof no conflicts, is it ok now?

[jtheoof]

👍 Although the commit message does not seem to follow the angular commit message conventions. I would preprend the commit the message with: fix(ngResource): ...

[netman92]

@jtheoof fixed

[caitp]

What if we just made this a switch statement for readability?

[netman92]

@caitp Done

[jtheoof]

👍

[caitp]

nit: can you change the test description to match the grammar of other ones in the file?

[netman92]

@caitp done

[caitp]

Other than the nit it looks great to me. Would be good if @gkalpak or @Narretz would take a look as well before merging

[gkalpak]

Nit: expect($httpBackend.flush).toThrow(...); is more concise and readable (here and below).
(Else you need a space after flush();.)

[caitp]

If it (flush) uses this at all, it's not an option anyways

[netman92]

@gkalpak fixed

[gkalpak]

I would leave it at .not.toThrow() (to account for the unlikely situation where the error message changes and the behaviour breaks (simultaneously)).
It's also more concise and readable.

[gkalpak]

LGTM 👍

_{TBH, I don't find it very useful, since having to recreate the resource class everytime a timeout promise is resolved doesn't seem very practical. But if people are using it, it's fine by me 😃}

[netman92]

@caitp Can you merge it?

[Narretz]

What @gkalpak said seems like the behavior is not well defined. Do we need to update the docs? Also, the commits must be squashed and the commit message doesn't follow our guidelines.

[caitp]

the behaviour seems pretty well defined to me @Narretz. It would be cool if you could override it on a per-request basis, but hey.

Some time ago, I had proposed that we allow letting you specify a factory function to produce the timeout promise, I can't remember if that's been done yet or not. That would solve the usability concerns.

@netman92 can you update the docs to indicate that the timeout parameter can be specified during initial resource class construction? Then I'll squash and merge

[netman92]

@caitp https://docs.angularjs.org/api/ngResource/service/$resource
and param timeout

timeout – {number|Promise} – timeout in milliseconds, or promise that should abort the request when resolved.

I think, it is already in docs.

[caitp]

Not really, it's not an accurate depiction of what happens

[netman92]

@caitp Sorry, but I do not know, what to add to docs.

[jtheoof]

I agree with @netman92. The documentation seems correct, the behaviour was incorrect in a sense that the Promise was copied, therefore not cancellable. I think it's good to merge.

[jvorcak]

The documentation seems correct to me as well. Do you think it will be merged eventually @caitp? I'd really need this for one of my apps.

[gkalpak]

You know what they say: It's never too late, right ?)
Well, I just realized there is an issue with this change:

If the user fails to re-instantiate the resource after having cancelled a request (i.e. after having resolved the timeout promise), all subsequent requests will fail (and this behaviour isn't even documented).
You can see it in action here (with the current master).

IMO, we should come up with a better approach to request cancelling for $resource (let's discuss in #13058).
At the very least, a warning should be added in the docs and a BC notice in the changelog (but I would prefer fixing the behaviour instead).

[petebacondarwin]

I agree - let's expedite #13058

[gkalpak]

#13058 has been superseeded by #13210.