process: add getActiveResourcesInfo()

[RaisinTen]

This is supposed to be a public alternative of the private APIs,
process._getActiveResources() and process._getActiveHandles(). When
called, it returns an array of strings containing the types of the
active resources that are currently keeping the event loop alive.

Signed-off-by: Darshan Sen darshan.sen@postman.com

[RaisinTen]

Before adding any tests or docs, I wanted to know if this PR is going in the right direction, which is why I opened this as a draft PR.

• This is getting exposed from the process object instead of async_hooks or any module because of the overheads mentioned in process: deprecate _getActive* private APIs in favour of async_hooks #40804 (comment) cc @mscdex @cjihrig
• This exposes just the summary of the resources instead of the actual resources as that was suggested in async_hooks: add getActiveResources #37262 (comment) cc @jasnell

[RaisinTen]

@nodejs/process review please

[RaisinTen]

@nodejs/process @Qard ping for opinions on the API and reviews

[vdeturckheim]

What is the use case for this? Would it be equivalent to creating an async hook and keeping track of all created and destroyed resources (I don't suggest doing it this way as destroy hooks have bad performances :) )

[RaisinTen]

What is the use case for this? Would it be equivalent to creating an async hook and keeping track of all created and destroyed resources (I don't suggest doing it this way as destroy hooks have bad performances :) )

@vdeturckheim Yes, that is the use case of this I'm aware of. I was initially planning to deprecate the private APIs in favor of async_hooks but didn't do so because of the overheads you mentioned.

[vdeturckheim]

That could indeed be useful for some. tbh, I would probably need to read the documentation to make up my mind fully :)

[RaisinTen]

@vdeturckheim I've added the docs, PTAL :)

[Qard]

No particular objections to the current state, but some suggestions on how it could be a bit simpler.

[vdeturckheim]

I would actually be expecting the method to return a list of Resource objects (the same as returned by executionAsyncResource) mostly because of the close naming between these methods.

[RaisinTen]

I would actually be expecting the method to return a list of Resource objects (the same as returned by executionAsyncResource) mostly because of the close naming between these methods.

@vdeturckheim I could rename it to something like getActiveResourcesInfo() instead as that is what it returns for now because of the concerns listed in #21453 (review).

The resource objects are completely private and undocumented, so it probably isn't ideal to expose them in the current state. If we go with the approach of exposing just the owner_symbol values of the resources, even that might not work because there are cases where an async resource might be active in the event loop but its owner_symbol key isn't assigned a value, which is what happens when a TCP object is created - the owner_symbol, which is supposed to be a net.Socket doesn't get created at the same time.

Is there a use case where we might need access to the actual async resources in place of some assorted info about them? I was going through how the public repos on GitHub use process._getActiveRequests() and process._getActiveHandles() and it seems most of them just use the number of resources and the constructor names of the resources. So I'm not sure if we even want to expose the asyncId and the triggerAsyncId of these resources because they probably are not of much use if we don't have AsyncHooks set up in the first place, which is what we can avoid doing if we use this API.

[vdeturckheim]

Indeed, getActiveResourcesInfo is clearer imho! good call!

[RaisinTen]

@vdeturckheim I've updated the name, PTAL

[vdeturckheim]

@RaisinTen lgtm as is. let's add some tests ^^

[Qard]

Ah, yes. New API needs new tests! 🧑🏻‍🔧

[RaisinTen]

@vdeturckheim @Qard I've added the tests, PTAL :)