feature request: a way to inspect what's in the event loop

[joeybaker]

I recently struggled with debugging a test suite that wouldn't exit. The (tape) tests all finished, but the final result wasn't printed out and the process just hung.

We eventually tracked the problem down to a few long-running setTimeouts that, while fine in app code, needed to be cleared in the tests so that the process could exit.

This debugging process would have been a lot easier if there was a way to see what V8 had in the event loop, by call stack. Perhaps an API like:

setTimeout(() => {console.log('hi')}, 2000)
setTimeout(() => {console.log('hi')}, 1000)

process.getEventLoop( (stacks) =>
  stacks.forEach(console.log.bind(console))
  // ['setTimeout file.js:2']
  // ['setTimeout file.js:1']

stacks is an array of arrays sorted by their order in the event loop and containing the call stack for each item.

Does this already exist? Is it possible?

[mscdex]

There are a couple of undocumented functions that can get you most of what is still on the event loop, but not necessarily everything last I heard: process._getActiveHandles() gets you handles that are still alive and process._getActiveRequests() gets you info about active libuv requests (IIRC).

I do agree that a polished version of these internal functions should be public because trying to find out what is keeping the event loop alive is a problem that I see/hear fairly often.

[joeybaker]

@mscdex Thanks for triaging. I wasn't aware for those methods so thanks also for the tip. As you say though… a formal API would be great.

[Olegas]

Wow! This is awesome! 👍

[alexfernandez]

Are there any examples on how to use process._getActiveHandles() and process._getActiveRequests()? I am trying to extract stack traces but no luck so far.

[petkaantonov]

@alexfernandez what stack traces?

[alexfernandez]

I am trying to extract the stack traces of the callbacks that keep my process from ending. This is something that a formal API should definitely support; and which I don't know how to do with the _getActive...() functions.

[bnoordhuis]

process._getActiveHandles() and process._getActiveRequests() don't collect stack traces because that's prohibitively expensive CPU- and memory-wise, and because there isn't necessarily a 1-to-1 mapping between internal handles and user-facing objects.

[alexfernandez]

Thanks for your quick answer. Is there any published example on how to use those two functions, so that I can be sure that I am not overlooking any interesting info in their interfaces?

[bnoordhuis]

Not really. I added them a few years ago to make debugging a little easier for core devs. They assume fairly deep understanding of the event loop's inner workings and probably aren't that useful for general purpose debugging (although many people do use them that way.)

[joeybaker]

Just documenting: @thlorenz is working on a module that uses _getActiveHandles() to kinda sorta do this. https://github.com/thlorenz/active-handles

[alexfernandez]

That is very cool, thanks!