Add hasRef to worker_threads.Worker

[SimenB]

What is the problem this feature will solve?

Jest has a --detect-open-handles flag which attempts to figure out (using async_hooks) what resources (timer/server etc.) are preventing a test run/node from exiting. To avoid false positives we perform filtering before presenting the list to the user. One of those things is to check if a Timer has been unrefed or not, via Timer.hasRef.

However, Workers have no hasRef, even though they have the {un}ref pair, so Jest will currently print false positives for Workers that have had unref called.

What is the feature you are proposing to solve the problem?

Add Worker.hasRef similar to the Timer API.

What alternatives have you considered?

No response

[targos]

What about other APIs that have an unref function? ChildProcess, FSWatcher, etc.

[SimenB]

I haven't gotten a bug report in Jest about them, so I have no opinion 😀

On a more serious note, I think it makes sense for ref, unref and hasRef to always exist together.

[benjamingr]

@SimenB would you be interested in contributing a PR? I am happy to guide you, the code is in io.js and worker.js mostly :)

[SimenB]

Io.js, that's a blast from the past! Happy to contribute it if it'll get accepted 🙂

[RaisinTen]

Sent a PR for this: #42756

[SimenB]

I tried this in the nightly now (19.0.0-nightly20220421c65746e05b) which I believe has the above fix. Jest now reports MESSAGEPORT instead of Worker, but it still reports something. Should MESSAGEPORT be ignored?

[RaisinTen]

@SimenB I'm assuming that happens after you merged jestjs/jest#12705?

That happens because the unref() method on the Worker object doesn't synchronously unref the associated MessagePorts. You may create a new issue for this.

If you ignore the MESSAGEPORT handles, i.e., bring back if (type === 'Timeout' || type === 'Immediate') { and add WORKER to the list, it would also ignore legit MESSAGEPORT handles that are open, like in

const { MessageChannel } = require('worker_threads');
const { port1 } = new MessageChannel();
port1.on('message', () => {}); // You would need to call `port1.unref()` to stop the event loop.

But I guess Jest users won't even notice it because --detect-open-handles never reported MESSAGEPORT handles in the first place. So I think MESSAGEPORT handles can be ignored for now and you may add WORKER to the list.

[SimenB]

After that, yes 👍 would waiting for some time help the message channel be closed?

[RaisinTen]

would waiting for some time help the message channel be closed?

nope, it just stays open forever unless you do something to close it

[SimenB]

Aha. But if it doesn't keep the process open, I think we can ignore it? Or would your example of new MessagePort keep the process open? I'm currently AFK, so can't test this myself

[RaisinTen]

Actually it does keep the process running.

[SimenB]

Oh 😅 how would you recommend we deal with this?

[RaisinTen]

We have 2 options here:

1. if we ignore messageport handles for now until someone comes up with a fix, jest users won't notice it because the bug was there from the beginning
2. or we can still report such false positives but the advantage is that in case the process keeps running, the logs would always include the root cause, which might not happen if we just form an allowlist of timer and worker handles in the report

I would recommend option 1 if the feature is not used very much and option 2 if it is used a lot. :P
I think https://github.com/mafintosh/why-is-node-running uses option 2, which is why I reported mafintosh/why-is-node-running#59.

[RaisinTen]

if we ignore messageport handles for now until someone comes up with a fix, jest users won't notice it because the bug was there from the beginning

Sorry, I misunderstood the default behavior. Jest reports handles as open by default, so excluding MessagePort would definitely be noticeable. So scratch option 1, option 2 is better IMO.

[RaisinTen]

@SimenB here's the fix for messageports btw - #42849

[SimenB]

Great, thanks!

[SimenB]

@RaisinTen can confirm the jest detection works correctly on 18.1.0, thank you!