Node: executionAsyncId doesn't return expected value in context of process.on('unhandledRejection')

[isaacs]

Version: 12.0.0-pre (78162ad570bfb991e2416c7850be546848a6fcc0)
Platform: Darwin geegaw.local 18.2.0 Darwin Kernel Version 18.2.0: Thu Dec 20 20:46:53 PST 2018; root:xnu-4903.241.1~1/RELEASE_X86_64 x86_64
Subsystem: async_hooks

https://gist.github.com/isaacs/1f8c5092ba7d67d9a5f4e342ff7778b7

I am building a domain-like implementation to catch errors using async_hooks. However, the executionAsyncId is reset to 0 on an unhandledRejection event, making it impossible for me to know if I ought to handle the error or crash.

The weird thing is that it only fails in this way when the promise rejection is within an async hop, such as a setTimeout. If the promise rejection happens at the top level, then I get the expected value of 1 as the executionAsyncId.

This is preventing me moving node-tap off of core domains. Fewer modules using domains means that it could be deprecated sooner :)

[isaacs]

This is still a problem in 13.3.0. It makes it really tricky to properly report errors when multiple promises are in use.

[ruyadorno]

/cc @jasnell @addaleax

[devsnek]

This is a problem for the unhandledRejection and rejectionHandled events. cc @nodejs/async_hooks

[jasnell]

Hmm yeah, we're not capturing the Async id when things like nextTick or a timer is created it seems. Will definitely need to investigate a fix

[addaleax]

Not sure how timers factor in here. It sounds more like we’d have to enter & exit the async context for the async resource associated with the Promise? That’s doable, but will have non-zero performance impact. Then again, for unhandled rejections a perf impact is maybe actually very acceptable? Also, not sure how #30959 factors in here yet, but i’ll take a look.

[coreyfarrell]

@addaleax According to Async Hooks | Promise execution tracking:

By default, promise executions are not assigned asyncIds due to the relatively expensive nature of the promise introspection API.

I would think unhandledRejection and rejectionHandled would only get accurate asyncId if an async_hook was already enabled, at that point the code has already opted in to the performance penalty?

[addaleax]

@coreyfarrell Right – I’m not suggesting to change that, only make it work when async_hooks are enabled