regression: UnhandledPromiseRejection is not fired until process is terminated

[aslushnikov]

• Version: v9.11.2, v10.11.0 and v11.1.0
• Platform: x86_64 GNU/Linux

Repro

1. save this is script.js:

Promise.reject(1);
setTimeout(() => {}, 2000);

2. run node script.js

Expected: the UnhandledPromiseRejection is reported as soon as it happens; the node.js process
exits after 2 seconds.
Actual: nothing happens for 2 seconds, then the node.js process exits and only then prints UnhandledPromieRejection.

This works as expected in v8.12.0

[aslushnikov]

(+cc @apapirovski who seems to be working on a related stuff)

[alexkozy]

It was regressed by following PR: #18207

[aslushnikov]

Any updates on this? This is really unfortunate since scripts just hang in inconsistent state without letting users know that something's wrong.

[vsemozhetbyt]

maybe cc @nodejs/promises-debugging

[Trott]

/ping @apapirovski

[Trott]

re-pinging @nodejs/promises-debugging

Is this a known issue? Works-as-expected/not-a-bug? Confirmed bug? Something else?

[BridgeAR]

AFAIK this is done to prevent the possibility of an infinite recursion inside of the unhandled rejection listener.

Ideally it would trigger the warning as soon as possible (as in: after a single tick). To prevent the recursion from being possible, that's not an option though (it should actually be possible for the case that no such listener is attached, since then there is no possibility for the recursion in the first place but this would result in different timings with the listener attached and without). However, we are able to trigger the warning on setImmediate / right after the microtask queue is exhausted. It is already implemented to trigger on queue exhaustion and therefore I guess it's a bug in the implementation for cases like these.

I am trying to look further into it but I am not that familiar with the microtask code.

[apapirovski]

The summary of this bug isn't quite correct. unhandledRejection was always fired as expected with the right timing. The only thing that didn't happen was logging the warning in case there was no listener for unhandledRejection. Fix is in #24632 but IMO this is a pretty insignificant bug.

[aslushnikov]

The only thing that didn't happen was logging the warning in case there was no listener for unhandledRejection. Fix is in #24632 but IMO this is a pretty insignificant bug.

Oftentimes program transitions into inconsistent state after throwing an exception and hangs forever; you never know if it's just slow fetching resources from the Web or it has thrown an exception until you terminate it.

Thank you @apapirovski for handling this ❤️

[Trott]

Fixed in 3ce9305