Resource.get xhr is not executed when updating to Angular 1.1.4

[tkremmel]

The code below works fine in 1.1.3, but does nothing in 1.1.4. It only prints "after get" and it seems as the get branch is never entered. From the debugging console I can see that no xhr request is issued.

app.factory('gridData', function($resource) {

    var csrf = 'CSRFTOKENEXAMPLE';

    return $resource('/list-management/rest/list/items/1/:itemID', {itemID:'@id'},{

         get: {method:'GET'},

         query: {method:'GET', isArray:true},

         save:{method:'POST', headers: {'X-CSRFToken' : csrf }},

     });

});


 gridData.get({itemID:item.id}, function(result) {
    //request ok

    console.log("in get status ok");

    dataView.updateItem(result.id, result);

    dataView.refresh();

 }, function(response) {

     //404 or bad

    console.log("bad request");

    if(response.status === 404) {

    }
 });

 console.log("after get");

[tkremmel]

Interestingly the get call is executed if wrapped into a $scope.$apply call:

$scope.$apply( function(){
    gridData.get({itemID:item.id}, function(result) {
    console.log("in get");
    dataView.updateItem(result.id, result);
    dataView.refresh();
 }, function(response) {
   //404 or bad
   console.log("bad request");
    }
)

See this discussion for details: https://groups.google.com/forum/?fromgroups=#!topic/angular/MkXDfkPDI_g

[admhemed]

same problem. your solution works as well.

[michaelahlers]

I've seen this, too. The following fails (the callback is never invoked).

Customers.query({
  terms : terms
}, function (results) {
  $log.log('Callback.', results)
})

But the following works fine.

$scope.$apply(function () {
  Customers.query({
    terms : query.term
  }, function (results) {
    $log.log('Callback.', results)
  })
})

Customers in this case is a $resource object.

Now, this is getting called from outside the Angular digest cycle, but it has worked prior to 1.1.4.

[aflock]

Seeing this as well, any update on if this is intended behavior? Also, any hunches on what change caused this? (presumably changes to the promise that is associated with $resource)

[michaelahlers]

@aflock (and others), on second thought, this probably is intended behavior. In my use case, the block I shared I called from a jQuery plugin. Any other AngularJS call that participates in the digest lifecycle would have the same requirement (to be wrapped in $apply). Why would $resource objects differ?

[aflock]

I don't think this is intended behavior. Take a look at this fiddle http://jsfiddle.net/s3THR/7/ .
If you run it with 1.1.4, the request is not run until a digest cycle is applied through ng-click.
If you downgrade to 1.1.1-3, the request is run as soon as the event is received.
My guess is, $resource was changed in a way that now requires a digest cycle to run.
This change isn't listed in changelog.md, so if it is intended behavior, it isn't documented anywhere.

To your point @michaelahlers why should resource be bound into a digest lifecycle? Shouldn't it be able to function independently? That's a facet of this I am unsure of, but my gut says it should be able by itself.

[michaelahlers]

@aflock, I seem to remember that an upcoming enhancement for $resource was that it's methods will now return promises. Those are most certainly bound to the lifecycle.

[c0bra]

I definitely think this is a bug in $http, possibly introduced in 4ae4681.

1. Here is @aflock's jsfiddle (which uses $resource) turned into a plunker: http://plnkr.co/edit/s25EEQ86RCTN2AvJNSmi?p=preview The main point is that the XHR get is not executed until AFTER the next $digest cycle. If you change the angular.js script tag from 1.1.4 to 1.1.3 it will work as expected.
2. Here is a modification of the plunker above using $http instead of $resource: http://plnkr.co/edit/BP2oxBxMGte1axB2gZmx?p=preview It fails in the same manner, and will work if you once again change from 1.1.4 to 1.1.3.
3. Here is yet another modification using $q and $timeout instead of $http: http://plnkr.co/edit/YcBoIpBW2yXuulmtI01h?p=preview It works fine.

[c0bra]

git bisect confirms, issue introduced in 4ae4681

[aflock]

It seems this was a known change introduced by this PR #2130, but not listed in the change log. Not sure if the consequences were totally known.

[mokesmokes]

@michaelahlers, I doubt this was intended behavior since the natural expectation is that $http and $resource run in the Angular execution context - and thus an additional $apply should actually cause an error. If for some reason this was intended, then as we can see from the numerous bug reports re this issue, there is widespread confusion. Personally - I reverted to 1.0.6 rather than modifying my code, with the expectation that future versions will be fixed back to "expected" and documented behavior. It would be nice to get guidance from the core team on this.

[mokesmokes]

So we still see the differences in behavior between 1.1.5 and 1.0.7 - I tried @c0bra's Plunkers above with the new releases. So my guess is that this is the new $http/$resource behavior. Can we _please_ get clarity and guidance on this from the core team? What are the new best practices for $http and $resource? I doubt the solution is to wrap $http calls with $apply - feels like a complete hack.
Thanks!