Skip to content
This repository has been archived by the owner on Apr 12, 2024. It is now read-only.

fix($resource): remove (broken) support for promises as timeout #13462

Closed

Conversation

gkalpak
Copy link
Member

@gkalpak gkalpak commented Dec 7, 2015

This fixes #13393 by:

  1. Reverting 7170f9d.
  2. Update the docs to note that promise as timeout is not supported.
  3. Log a warning when someone tries to use it.

The commits could/should be squashed before merging. We probably need a BC notice (since the broken support for promises as timeout has sneaked into v1.4.8, right ?

* should abort the request when resolved.
* - **`timeout`** – `{number}` – timeout in milliseconds.<br />
* **Note:** In contrast to {@link ng.$http#usage $http.config}, {@link ng.$q promises} are
* **not** supported in $resource, because the same value has to be re-used for multiple
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same value would be used?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I copied it from v1.5.x. I should change it there too, right ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it makes sense to you.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated it and changed it on master as well (3694390, da5db4b).

@petebacondarwin
Copy link
Contributor

Some minor comments but lgtm

@gkalpak gkalpak force-pushed the v1.4.x-fix-resource-promise-as-timeout branch from ed915fe to 66d1330 Compare December 8, 2015 13:24
gkalpak added a commit that referenced this pull request Dec 8, 2015
@gkalpak gkalpak force-pushed the v1.4.x-fix-resource-promise-as-timeout branch from 66d1330 to 7fe6201 Compare December 8, 2015 15:15
@gkalpak
Copy link
Member Author

gkalpak commented Dec 8, 2015

@petebacondarwin, I addressed the comments. What about a BC ?

Here's the situation:

  • Up to v1.4.7 (included), using a promise as timeout in $resource, would silently fail (i.e. have no effect).
  • In v1.4.8, using a promise as timeout will have the (buggy) behaviour described in Issue with canceling XHR request using promises - fixed #12525 #12657 (comment). (I.e. it will work as expected for the first time you resolve the promise and will cancel all subsequent requests after that - one has to re-create the resource class. This is not documented.)
  • With this change, using a promise as timeout will log a warning and ignore the timeout value.

Do we need a BC notice ?


It just occurred me: You said we should recommend an upgrade to 1.5 in the docs and warning message.

…ning

Promises never worked correctly as values for `timeout` in `$resource`, because the same value has
to be re-used for multiple requests (and it is not possible to `angular.copy()` a promise).
Now (in addition to ignoring a non-numeric `timeout`), a warning is logged to the console using
`$log.debug()`.

Partly fixes angular#13393.
@gkalpak gkalpak force-pushed the v1.4.x-fix-resource-promise-as-timeout branch from 7fe6201 to 6d5141e Compare December 8, 2015 15:44
@gkalpak
Copy link
Member Author

gkalpak commented Dec 8, 2015

I updated the docs and the warning message to add a recommendation to upgrade to v1.5 if one needs support for cancellable $resource actions.

gkalpak added a commit that referenced this pull request Dec 8, 2015
@petebacondarwin
Copy link
Contributor

Yes, we should put a simple BC notice along the lines of your comment #13462 (comment)

I think in general it is safer to have BCs where they were not needed rather than the other way around

@petebacondarwin
Copy link
Contributor

Landed as 4748652 and previous three commits.

@gkalpak gkalpak deleted the v1.4.x-fix-resource-promise-as-timeout branch December 8, 2015 19:01
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants