Question about `trimFalsePositives`

[thomasfulton]

Just wondering what the reasoning/motivation behind trimFalsePositives is? It appears that all it does it ensure that the async id in the after block is the same one that most recently executed in the before block. Please forgive my rudimentary understanding of Node's single-threaded nature; how is it possible that an after block can execute after a different before block than the current async resource?

[naugtur]

The thing is some of the ways libraries implement async stuff can mess with async context and hooks and things can get mixed up. There's APIs for the libraries to preserve async context. This detection feature will avoid reporting stuff that got mixed up by one of these.

BTW async_hooks will be going away and the stack trace cleanup isndated, so don't get used to this package too much 😅

[thomasfulton]

We use a variation of your technique to detect event loop blockers but it gives totally wrong results a small portion of the time. I think we will try your approach. Unfortunate that async_hooks are going away; it will leave us without any good way (that I know of) to detect event loop blocking operations. Thanks so much for your help!

[naugtur]

Some potentially maybe theoretically viable ideas I never explored:

Low level

• Use the same method that's used for stack sampling in performance metrics and instead if collecting them, take note of the most recent values and if it's not moving along, report blockage.
• V8 coverage features theoretically should have access to information necessary for the same

High level

• use the event loop busy metric and crash/coredump or otherwise read current stack on peaks.