Angular 1.6 - Possibly unhandled rejection: canceled

[achenxp]

Click on column header to sort data and it throws "Possibly unhandled rejection: canceled" error under Angular 1.6.

http://plnkr.co/edit/bXEXwcvHz1dK655nHpeT?p=preview

[mportuga]

angular 1.6 is currently not supported by UI-Grid, but thank you for the information

[vincent-ollivier-everysens]

+1
Error throws immediatly at load with Angular 1.6

[sebastian-zarzycki-apzumi]

This is a result of timeout.cancel (about 8 times in code). UI-Grid creates own promise with .then(), right after defining the cancel. This is the main offender, but there are others:

 Grid.prototype.queueRefresh = function queueRefresh() {
                    var self = this;

                    if (self.refreshCanceller) {
                        $timeout.cancel(self.refreshCanceller);
                    }

                    self.refreshCanceller = $timeout(function () {
                        self.refreshCanvas(true);
                    });

                    self.refreshCanceller.then(function () {
                        self.refreshCanceller = null;
                    });

                    return self.refreshCanceller;
                };

simple change to the then part to

self.refreshCanceller.then(function () {
                        self.refreshCanceller = null;
                    }, angular.noop)

[paambaati]

For anyone that wants a workaround (not recommended, though), you can globally silence unhandled promise rejections like this —

app.config(['$qProvider', function ($qProvider) {
    $qProvider.errorOnUnhandledRejections(false);
}]);

[dominusbelial]

sebastian-zarzycki-es solution prevents the "Possibly unhandled rejection: canceled" error but the offending code should be rewritten to prevent hiding possible errors.

[sebastian-zarzycki-apzumi]

Can $timeout.cancel ever throw an error?

[Nickproger]

+1
Same problem... Waiting for it...

[ivorobkalo]

+1
the same

[dominusbelial]

not sure about that sebastian but angular 1.6.0 conforms to promises/a+ so proper handling should look like you suggested $promise.then(() => {},angular.noop) or $promise.then().catch() else we get the "Possibly unhandled rejection: canceled", notice you should prefer the latter as 1.6.0 migration suggest... https://docs.angularjs.org/guide/migration#migrate1.5to1.6-ng-services-$http

[sebastian-zarzycki-apzumi]

Yes, I agree. All I'm saying is that the error response will probably never trigger anyway in this case, so angular.noop will do just fine. But, yeah, using proper then().catch() is better, even if catch would be empty.

[valdirviana]

+1
Same problem with ui-grid

[mkjois]

I tried using the $qProvider.errorOnUnhandledRejections(false) config on just the module that encapsulates my ui-grid, but it turns out that providers are singletons and this affects all of my modules that use $q.

Is there a way to have the one module use a sort of "separate $q" where I could ignore the unhandled rejections in that module only? Or any better workarounds?

[mkjois]

@sebastian-zarzycki-es Could you point out where in the code you found that block? I might have to tackle this myself

[sebastian-zarzycki-apzumi]

Just search for $timeout.cancel and look for any .then() connected to them in near, as they create new promise, that has to handle the error part with catch.

[bostondevin]

+1 support angular 1.6

[dominusbelial]

using sebastian-zarzycki-es solution i have added ".catch(angular.noop)" to all the offending promises on the latest 4.0.2 uigrid for angular 1.6.1... all features are working for my implementation and not getting the Possibly unhandled rejection: canceled...
ui-grid.zip

[mkjois]

@dominusbelial Do you happen to have your fix on a GitHub repo?

[mportuga]

We are willing to accepts pull requests for this fix

[cybermerlin]

in branch i fixed this trouble

[jasonwr]

@cybermerlin I just tested out the window.setTimeout from your branch and the problem still remains when I click on a column header to sort by column.

[dominusbelial]

forked and updated in my branch

[mattbrunetti]

@dominusbelial Put in a PR? 😄

[dominusbelial]

@mattbrunetti will do, this is my first time!

[Sheeryada]

+1

[l8nites]

+1

[takotuesday]

+1

[masterOL]

+1

[hendriklammers]

+1

[YahiaDev]

+1

[YahiaDev]

Any news about the new version ?

[derekm]

The proposed fix is quite a hack. It fixes one NPE and then tacks a bunch of empty .catch()s onto everything. Seems like a silly thing for Angular 1.6 to impose on projects.

[mattbrunetti]

I agree with @derekm.. the proposed fix seems pretty wrong. There must be a solution that doesn't simply swallow all unhandled rejections, which is pretty reckless.

[sebastian-zarzycki-apzumi]

Whoa, these comments. Does anyone even know how Angular works?

Angular's $timeout returns promise and all they did was just add a warning to all promises that do not have both results handled. In case of $timeout this is just redundant, because $timeout itself cannot ever result with an error and if you cancel it manually, you care even less. Take a look at Angular's $timeout.cancel implementation:

 timeout.cancel = function(promise) {
      if (promise && promise.$$timeoutId in deferreds) {
        // Timeout cancels should not report an unhandled promise.
        deferreds[promise.$$timeoutId].promise.catch(noop);
        deferreds[promise.$$timeoutId].reject('canceled');
        delete deferreds[promise.$$timeoutId];
        return $browser.defer.cancel(promise.$$timeoutId);
      }
      return false;
    };

Does that comment ring any bell?

[dgsmith2]

I fear this is going to turn into a flame war, but I personally DO agree with the changes.

By supplying a .then(handleTheGood) you are implicitly supplying a .noop rejection callback. Angular 1.6 now encourages developers to be explicit in handling either outcome of a promise. In 1.6 if a promise you expected to always resolve for some reason didn't you get information (i.e., error message in the console) about an unhandled rejection that you should obviously be handling.

Also, if you are coding promises according to spec, you aren't using the .finally that $q provides and therefore already handling rejections explicitly, even if they are simply a .noop to achieve a "finally". (.then(handleTheGood, handleTheBad).then(handleRegardless) or .then(handleTheGood).catch(handleTheBad).then(handleRegardless, with both assuming your handleTheBad doesn't return a rejected promise)

[Oceanswave]

Angular now warns us when there's an unhandled rejection, we don't want to shut that off globally, but we also don't like the solution that suppresses unhandled rejections in situations that an unhandled rejection is not important in cases where the promise is part of the library and can't be controlled by the developer.

wut?

[niveditapatil]

Any idea about when is ui-grid planning to support Angular JS 1.6 version?

[DoubleDot]

Any update on this?

[alinleonard]

+1

[MatejQ]

I don't know whether ui-grid already handles these cases but if not, you can configure angular to ignore unhandled promise rejections (reverting to pre-1.6.0 behavior).
(typescript code following)

        App.AppModule.config([
            "$qProvider",
            ($qProvider: any) => { // Q Provider is not part of .d.ts for some reason
                // suppress angular errors about unhandled promise rejections since 1.6.0
                $qProvider.errorOnUnhandledRejections(false);
            }
        ]);

[adrienplg]

+1

[SensationSama]

See angular-ui/ui-router#3246

[7urkm3n]

+1

[ITAndy23]

I get the same error running the ui-grid for the first time using Angular 1.6.4.
What's the recommendation to work around it? Revert to an earlier version of Angular?

[mohanrao]

+1

[jasonwr]

+1

[mmaask]

+1

[michelj90]

+1

[doracl]

+1

[jspencersharpe]

+1

[pwdl]

+1

[kyleThayerXpanxion]

+1!!

[cybermerlin]

fixed this trouble in

https://github.com/cybermerlin/ui-grid/tree/develop

[GlennHogent]

+1

[besil]

+1