Conversation
| // tracked. | ||
| if ( | ||
| type === 'PROMISE' || | ||
| type === 'TIMERWRAP' || | ||
| type === 'ELDHISTOGRAM' || | ||
| type === 'PerformanceObserver' || | ||
| type === 'RANDOMBYTESREQUEST' || | ||
| type === 'DNSCHANNEL' || | ||
| type === 'ZLIB' || | ||
| type === 'SIGNREQUEST' | ||
| ) { | ||
| if (type === 'PROMISE') { |
There was a problem hiding this comment.
Only TIMERWRAP was added before jest repo was migrated to ts, it's a bit troublesome to find commit records, I don't have confirmation.
For other types, I have checked the submitted PRs and tests, and they are theoretically safe.
Anyway, this is in a major release and can be safely tested in a beta release.
There was a problem hiding this comment.
include PerformanceObserver to fix CI?
There was a problem hiding this comment.
Let me try to destroy it. #13417 (comment)
There was a problem hiding this comment.
Original issue with a reproduction: #11051
If node doesn't require a disconnect to exit cleanly, we shouldn't report it
There was a problem hiding this comment.
We can probably add
const client = require("prom-client");
client.collectDefaultMetrics();as an integration test
There was a problem hiding this comment.
I'm not really sure what detectOpenHandles is for now, technically most of the object types removed by this PR should not block process exit, but it seems that some users use this to detect memory leaks/object leaks. Would love to hear your opinion.
There was a problem hiding this comment.
It's used to detect handles keeping the process running after tests complete (such as a rogue server, setInterval (without unref() or clearInterval)) etc.. It shouldn't be used for memory leaks per se (although open handles indicate a missing cleanup of some sorts), but since it forces GC runs it oftens helps with memory usage
There was a problem hiding this comment.
essentially to find out why https://jestjs.io/docs/cli#--forceexit would be needed
| exports[`prints out info about open handlers 1`] = ` | ||
| "Jest has detected the following 1 open handle potentially keeping Jest from exiting: | ||
|
|
||
| ● TCPSERVERWRAP | ||
| ● DNSCHANNEL,TCPSERVERWRAP | ||
|
|
||
| 12 | const app = new Server(); | ||
| 13 | |
There was a problem hiding this comment.
I modified the logic here and now it will report all types at the same stack.
Not sure if the prompt message needs to be modified, but I'm not good at English and can't do anything about it.🤦♂️
There was a problem hiding this comment.
Awesome change! We could probably land this on main?
There was a problem hiding this comment.
Yes, I can do this, but the tests in the main branch don't reflect this. I couldn't think of a test example like this for a while. (DNSCHANNEL is ignored in main branch)
| await asyncSleep(100); | ||
| await asyncSleep(0); | ||
|
|
||
| if (activeHandles.size > 0) { | ||
| // For some special objects such as `TLSWRAP`. | ||
| // Ref: https://github.com/facebook/jest/issues/11665 | ||
| runGC(); | ||
| await asyncSleep(30); |
There was a problem hiding this comment.
Checking length is free, let's check it first. Another 100ms might be a bit long? I modified it to 30ms, you can also modify it to 0-10ms if you want, lol.
There was a problem hiding this comment.
as low as possible while still passing all tests (without introducing flake) seems ideal 😀
|
The failure in CI I should know how to fix, but I can't reproduce it locally (win) anyway, which is weird. Even I can't reproduce it using gitpod (linux). 😕 Seems to be related to node version, node18 on CI passes, node16 fails while failure is expected. Yes, this seems to be an undocumented behavior, there is no such type |
|
CI error seems resolved |
|
/easycla |
✅ Deploy Preview for jestjs ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Hey @liuxingbaoyu, finally got back to this 😀 Could you sign the CLA? 🙂 |
9e51506 to
b0d7c51
Compare
|
Sorry for forgetting this! |
|
Wonderful, thanks! |
|
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. |
Summary
Removed some previously ignored detection types.
Ref: #13414
Test plan
CI GREEN