unhandledRejection event not firing (v0.7.4) about asyncawait HOT 5 CLOSED

Hi @Zaggen,

Yes, your issue is clear. It's not a bug, but it's certainly due for an update/improvement.

The unhandledRejection event was added to Node relatively recently (v1.4.1). It is only triggered by native Promises whose rejection goes unhandled.

Node had neither native Promises nor unhandledRejection when I originally wrote asyncawait. I used the bluebird promise library instead. Up until now there has been little reason to switch to native promises, however I'd say your issue here might be a good reason to reconsider that.

Moving away from bluebird promises might adversely affect performance, so I think its worth investigating first whether node's unhandledRejection can be fired by an unhandled bluebird rejection.

I'll look into this when I have time. What I'll try is subscribing to bluebird's global unhandledRejection event and having that fire node's unhandledRejection event. If you feel like experimenting, maybe try that yourself and let me know if it works.

from asyncawait.

Hey @yortus , thanks for the fast response. You are right, this something relatively new in node for native promises. I've tested bluebird (2.9.30) and it supports this (as stated in their docs from v 2.7):

Promise = require('bluebird')
new Promise.reject(new Error('i should die now right?'))

Triggers the process unhandledRejection event

I'm not sure how your module works internally, but since bluebird is already firing that event, is there something catching it in async/await? that prevents its propagation to the global event?, if that's the case, i guess there is no reason to manually trigger the native promise event if bluebird is already doing it.

I'll try checking into that as soon as i have time, can you point me out in the right direction in your module, so i might get there faster.

So far the only thing that i've understand is that when an error is found in src/async/fiberManager.js

This fn gets called

function catchBlock(runCtx, err) {
    // The wrapped function threw an exception. Notify any waiters.
    if (runCtx.callback)
        runCtx.callback(err);
    if (runCtx.resolver)
        runCtx.resolver.reject(err);
}

And that runCtx.resolver.reject(err); resolver object is created by the defer() fn that is in fact a bluebird promise, and since it was rejected, it should trigger the event (you are using 3.x version of bluebird), but there should be something that i'm missing. I'll try to get some time to read the code more carefully.

from asyncawait.

Hey @Zaggen,

OK, I've investigated this and had a few surprises.

Firstly, I added a unit test that shows that the unhandledRejection event is fired if an async function has an unhandled rejection. This surprised me as I thought the problem was that it was not firing. If you checkout the latest commit on the master branch, you can run this new test for yourself.

Secondly, I checked the node.js documentation regarding unhandledRejection. It turns out that unlike unhandled exceptions, unhandled rejections do not crash the process. You can see this for yourself by executing a script like the following:

setInterval(() => console.log('still running...'), 500);
var unhandled = new Error('unhandled');

// Uncaught exceptions DO crash the process by default
//throw unhandled;

// Uncaught rejections DO NOT crash the process by default
Promise.reject(unhandled);

So it looks like what you want is to add your own handler to crash the process on an unhandled rejection. I tried the following and it works (try adding it to the script above):

process.on('unhandledRejection', er => {
    console.log('Unhandled Rejection: ' + er);
    console.log('Terminating process...');
    process.exit(1);
});

Does that adequately deal with this issue for you?

from asyncawait.

Hey @yortus i realized that yesterday, but my main issue remains (i've tested again with a console.log and process.exit), the event is not getting called, so i can't in turn call process.exit(). I'm going to run the new tests you've added to see if they work on my machine. If they are working for you then it might be an issue with the version i'm using? I'm running 0.7.4, so let me check if by updating everything works, and if the unit test passes, then it must be something else in my app environment that is conflicting with it.

from asyncawait.

Ok indeed the issue is now fixed, the problem was the version of bluebird you had 2.10.0, prior to the asyncawait v 1.0.2 from January, and since bluebird started supporting this from version 2.7 it was never going to work. So this issue is officially fixed, if someone runs into the same problem its just a matter of updating asyncawait.

Thanks a lot for your assistance, i really appreciate that, and its cool that we have an extra unit test to make sure it works :)

pst: Should we change the title of the issue to unhandledRejection not getting fired?

from asyncawait.