Possibly unhandled rejection with Angular 1.5.9 #2889
Comments
|
Same issue with me to using angular js v -1.5.9 and ui-router v-0.2.15. |
|
Yes, in my case I was a 1.4.2 before attempting the 1.5 upgrade. Reverting to 1.4.x does make the error go away. |
|
happened the same upgrading from 1.5.8 to 1.5.9 this can be linked to #2699 anyway, a quick fix is to use this: https://docs.angularjs.org/api/ng/provider/$qProvider in order to set errorOnUnhandledRejections to false |
|
@lucax88x, I attempting to apply the workaround you mentioned but not having any luck. Likely, I'm not understanding what you intend for me to do. Apologies if I am missing something obvious, but there does not appear to be useful examples of how to do this via google search. I have modified my application's .run() function to call $q.errorOnUnhandledRejections(false); However, it keeps telling me that errorOnUnhandledRejections is not a function. Changing to .run() to literally set the value ($q.errorOnUnhandledRejections = false) succeeds (does not produce an error), but does not have any affect on the possibly unhandled rejection {} errors. Is it nor possible to make this change globally in the application? Do I need to do something to each and every time I access $q? TIA! |
|
try $qProvider.errorOnUnhandledRejections(false) |
|
I'm sorry for the basic question, but I am missing something obvious. I have tried to inject $qProvider in both the typical manner - Both approaches result in Unknown Provided $qProviderProvider errors. Of course, without injecting a reference somehow, the $qProvider.errorOnUnhandledRejections(false) fails with an unknown $qProvider error. I've also add 'ng' to my module list as well as attempted via the following approach, without success: How do I get a reference to this bad boy in my .run() function? |
|
Not .run(), but rather .config() |
|
@christopherthielen Of course, that makes more sense. Thank you! Does anyone know if an official 'fix' for this issue is/will be worked, or is this the proper solution? |
|
Would like to know aswell if the 1.5.9 will have this error unless we don t set to false the errorOnUnhandledRejections |
|
1.6.0-rc.0 has the same problem and is solved via the same workaround: This error throwing ideally should be off by default and backward compatible. |
|
This is fixed in 1.0 branch |
|
closed by 66ab048 |
|
I am getting this issue still with ui-router v-0.3.2 and angularjs v-1.6.0-rc.2. Specifically when closing UI Bootstrap modal dialogues (ui-bootstrap v-2.3.0). The $qProvider workaround resolves this. |
|
Same here 1.6.0 |
2 similar comments
|
Same here 1.6.0 |
|
Same here 1.6.0 |
|
Same here 1.6.0. Should be reopened. |
|
1.6 - same issue |
|
Same here 1.6.0 |
|
I just moved from 1.5.8 to 1.6.0 and ui-router#1.0.0-beta.3 resolves the issue. |
|
I am using 1.6.0 and ui-router#1.0.0-beta.3 but now whenever I go to a route, it urlencodes the route so instead of getting a#/b/c I get a#%2Fb%2Fc and the navigation fails |
|
I got this error everytime I use .filter .forEach on some arrays. as simple as this. |
|
Same here 1.6.0 |
|
Same here I'm using 1.6.0 and 1.0.0-beta.3. some of my modal are not working because of this issue. |
|
same here 1.6.0 and 0.3.2 |
|
I had the same issue while using responsivevoice.js 3rd party app for those wants to track the problem. https://gist.github.com/anchetaWern/ed6e841555602656e6ae |
Credits for a GREAT debugging help via angular-ui/ui-router#2889 (comment)
|
seeing the issue again with angular 1.6.3 and ui router 0.4.2 |
|
same here |
rm -rf angular.js |
|
See also: #3404 |
|
1.0.4 is released |
|
Got some errors with 1.x.x: |
|
@christopherthielen Could someone confirm that, 1.0.4 fix this problem ? |
|
We are seeing this issue Angular 1.6.4 and angular-ui-router 1.0.4. I've been trying to hunt down any unhandled rejections on our end, but it seems to be getting rejected somewhere in the transition. See the following log/trace: Our onStart hook is basically checking if a user is authenticated or not. If not, it should redirect them to the login page (really simplified below): |
$provide.decorator("$exceptionHandler", ["$delegate", function ($delegate) {
return function (exception, cause) {
if (!cause) return; //do nothing (ignore) exception in this case === 'Possibly unhandled rejection: undefined'
$delegate(exception, cause);
};
}]);works for me. |
|
Got the same block as @aphairpq: It throws the "Possibly unhandled rejection: {"$id":0,"type":2,"message":"The transition has been superseded by a different transition"...... error Followed the q decorator tip above to get the trace, and toCheck.stack shows: According to the docs, returning a target state, the router should redirect, and it does. It's just that annoying error message floods the console every time. Even tried to return a promise, just for the hell of it. Same result: I can't see that there are other state's being initiated, no other hooks are in play and generally nothing to indicate that this should not work. Silencing the errors is not an option. ui-router 1.0.6 |
|
I think I also have a similar issue as @aphairpq and @andreaslarssen I enabled to trace with the decorator made by @christopherthielen I'm not seing the issue. I have angular 1.6.5 and ui-router 1.0.3 |
|
Do you have some wisdom to share, @christopherthielen? |
|
@aphairpq this is a very late response, but I was unable to reproduce your scenario as described: |
|
@andreaslarssen what is defined in the hook inside Your stack trace suggests that the |
|
@tiagomsmagalhaes try using a redirect instead: runtimeFunction.$inject = ['$transitions', '$trace', 'AuthService'];
function runtimeFunction($transitions, $trace, AuthService) {
$trace.enable('TRANSITION');
$transitions.onStart( { to: 'dashboard' }, function(trans) {
var $state = trans.router.stateService;
var AuthService = trans.injector().get('AuthService');
return AuthService.getUserStatus()
.then(function (res) {
if (!res.data.status)
return $state.target("index");
})
});
} |
|
I updated the q decorator such that it prints out the unhandled rejections stack traces to the console. It only works if you are not using minification (because it parses the stack traces). Also I only tried it with Chrome. http://plnkr.co/edit/GGVhS6gcxFDi0es36109?p=preview // Decorate the $q service when app starts
angular.module('qDecorator', [])
.decorator('$q', ['$delegate', function($delegate) {
// Create a sample promise.
var promise = $delegate.when();
// Access the `Promise` prototype (nonstandard, but works)
var promisePrototoype = promise.__proto__;
var isPromisePrototype = typeof promisePrototoype === 'object' &&
['then', 'catch', 'finally'].reduce(function(acc, key) {
return acc && !!promisePrototoype[key];
}, true);
if (isPromisePrototype) {
// The angular $q promise implementation sets `$$state` once in its Promise varructor:
//
// function Promise() {
// this.$$state = { status: 0 };
// }
//
// Hijack the promise behavior by adding a setter for `$$state` on the Promise prototype.
// The setter is run each time a promise is created (via any method: $q.when(), promise.then(), etc).
//
// The setter records the stack trace in which the promise was created.
Object.defineProperty(promisePrototoype, '$$state', {
set: function($$state) {
this._$$state = $$state;
if (typeof $$state._status === 'undefined') {
this._value = this.value;
this._logged = false;
// Define a getter for `Promise.$$state.value`
// ('value' is the resolved or rejected value)
Object.defineProperty($$state, 'value', {
enumerable: true,
set: function(val) {
this._value = val;
},
get: function() {
// Check if this is the "Possibly unhandled rejection" handler. return the stack trace instead
if (this.status === 2 && this.pur && new Error().stack.includes('processChecks')) {
if (!this._logged) {
this._logged = true;
console.error(this._value)
}
return this._context;
}
return this._value;
},
});
}
// Create an Error object and use its stack trace
$$state._context = new Error('Possibly unhandled rejection (promise creation stack)');
},
get: function() {
return this._$$state;
},
enumerable: true,
});
// Whenever promise.then() (or .catch or .finally) is called, a new promise is created.
// Add the chained-from-promise's stack to the new promise's stack to allow analysis of the full promise chain
var realThenFn = promisePrototoype.then;
promisePrototoype.then = function() {
var chainedPromise = realThenFn.apply(this, arguments);
var prevContext = this.$$state && this.$$state._context;
var chainedContext = chainedPromise.$$state && chainedPromise.$$state._context;
if (chainedContext) {
try {
chainedContext.stack = chainedContext.stack +
'\nPromise Chained from:\n' +
prevContext.stack;
} catch (ignored) {}
}
return chainedPromise;
}
}
return $delegate;
}]); |
|
@christopherthielen: Holy cow, you're right! Was using the finally handler to remove a loading screen. Good catch (pun intended), thanks! |
|
This was my issue in case it helps someone else. It had nothing to do with ui-router, well at least as far as I can see, maybe a red herring. |
Just wanted to highlight this gem of a find & replace fail ( And on a more constructive note; I was running into this unhandled rejection issue on account of routes not resolving due to 401 errors for asynchronous resolves. However, we handle those 401's elsewhere and try to refresh the user's session in that case, so an error is not necessary. Yet UI router throws these exceptions and they are then caught in the global exception handler. So to address this, we filter them out in the exception handler decorator: //Exception handling
$provide.decorator('$exceptionHandler', [
'$log', 'Raven',
function($log, Raven) {
return (exception, cause) => {
//No cause, ignore unhandled rejection warnings for undefined
if (!cause) {
return;
}
//UI router non authenticated errors
if (
typeof cause === 'object' &&
typeof cause.detail === 'object' &&
cause.message === `The transition errored` &&
cause.detail.status === 401
) {
return;
}
//Capture exception and log
Raven.captureException(exception);
$log.error(exception);
};
}]); |
|
This issue has been automatically marked as stale because it has not had This does not mean that the issue is invalid. Valid issues Thank you for your contributions. |
and others
When using ui-router v-0.2.18 and angularjs v-1.5.9 I keep getting this error 4 times:
Possibly unhandled rejection: {}
I was not getting this error with 1.4.x angular verisons, but am now that I have upgraded. Google searches are not turning up much related to this issue.
I also noticed this error shows up as soon as I insert the ui.router module.
The text was updated successfully, but these errors were encountered: