Fix detectOpenHandles false positives for some special objects such as TLSWRAP

[liuxingbaoyu]

Summary

Fixes: #11665

Some objects need to be garbage collected before being destroyed, currently detectOpenHandles gives false positives for this case, let's do a garbage collection when needed.

Test plan

CI Green

[liuxingbaoyu]

This should technically fix the linked issue, but in practice I'm not sure because some users really don't actually destroy the connection. (There may even be some libraries that don't provide such a destroy API)🤦‍♂️

[SimenB]

Nice!

[SimenB]

This should technically fix the linked issue, but in practice I'm not sure because some users really don't actually destroy the connection. (There may even be some libraries that don't provide such a destroy API)🤦‍♂️

It makes sense to do this regardless - it'll at least get rid of false positives 👍

[liuxingbaoyu]

I found something, not sure if it's good or bad.

#11278
Something similar has been done in this PR, but in the end it was not adopted.
#10417
Then a wait was added to this PR.
From my simple understanding, waiting in the first PR caused another problem, which was fixed in the second PR and only used a wait. Looks like garbage collection is safe.

I re-tested https://github.com/facebook/jest/blob/1ba37a3fb6ed27f9c2019cc052db64976a5e8533/packages/jest-core/src/collectHandles.ts#L65-L79 and found that now (after this PR) even only PROMISE is kept, the test can also pass normally. (yarn jest collectHandles, yarn jest detect)

There was a small failure here, let's simply assign null, and now it works! This is really great!
(This would not be the case in the real world, since the variable is naturally destroyed after the function returns)

Everything looks great, so maybe we can consider removing these skip types?
Maybe in the next major release?
Node is complex and jest is widely used, so I personally tend to have special skipped detections reinstated in major releases, which reduces the impact of accidental regressions (node ​​is really complex, I'm not sure if any of these types contain unresolvable cases that have to be skipped) and won't break the user's code, although there may be some leaks, but insignificant.😃

[liuxingbaoyu]

The issue in the CI is weird, I haven't seen it in other PRs, but I can't think of anything to do with this PR, even the CI is green on the first commit.😕

[SimenB]

Everything looks great, so maybe we can consider removing these skip types?
Maybe in the next major release?

Sounds like a good idea - mind opening up a PR with that? I can add it to a Jest 30 milestone so we don't forget 🙂

The issue in the CI is weird

Just flake 🙁

[jdanielsyeah]

I'm still getting the error when testing a simple call with axios:

Jest has detected the following 1 open handle potentially keeping Jest from exiting:

  ●  TLSWRAP
> await axios({...

    "axios": "^1.1.3",
    "jest": "^28.0.1",
    "ts-jest": "^28.0.8",
    "ts-node": "^10.9.1",
    "typescript": "^4.8.2"

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.