Hey! We (I work at Ashby) are on latest node 16. We'll update the post to reflect that. Happy to chat over email (edit: found your email and will reach out)
We could break blocked-at into two layers so that you could provide the data collection mechanism.
You could report to datadog while using the false positive filter.
Also, there's a bunch of tools you could use before you deploy blocked-at or async hooks at all.
Note it's midnight here and I'll stop responding very soon :D
Comments
Hi, blocked-at author here.
Get in touch over email if you want to explore further.
Some quick comments:
- I didn't notice the node version or you didn't state it. The impact from async hooks is _vastly_ different between node versions
- I need to update the package a bit, I've got a known perf improvement to add AFAIR.
- your implementation is likely to produce false positives. The trick to prevent (some) false positives is the most valuable part of the lib.
Also, take a look at the event loop utilization metric introduced last year https://m.youtube.com/watch?v=WetXnEPraYM&list=PL0CdgOSSGlBa...
And for more of my diagnostics experiments see debugging-aid package https://www.npmjs.com/package/debugging-aid
Hey! We (I work at Ashby) are on latest node 16. We'll update the post to reflect that. Happy to chat over email (edit: found your email and will reach out)
We could break blocked-at into two layers so that you could provide the data collection mechanism. You could report to datadog while using the false positive filter.
Also, there's a bunch of tools you could use before you deploy blocked-at or async hooks at all.
Note it's midnight here and I'll stop responding very soon :D