The process exits normally, but I get an open handle error.

[CatsMiaow]

• Node.js v12.16.2
• Jest v26.0.1

Related issues #6423 (comment)

This code terminates the process normally but Jest gives an open handle error.

import { promises } from 'dns';
//= const { promises } = require('dns');

const { Resolver } = promises;
const resolver = new Resolver();
const servers = resolver.getServers();
console.log(servers);

[thymikee]

Can you provide a minimal repro which can be downloaded?

[CatsMiaow]

https://github.com/CatsMiaow/jest-issues-9982
like this?

[Cosmin-Gramada]

Still seeing this issue in the latest version Jest to date, v26.4.0.

[cschwebk]

Still seeing this issue.

Node 14.15.0
Jest 26.4.2

[mifi]

Is there any workaround? it causes jest to hang forever and never complete.

[mksmzpsv]

@mifi you can use --forceExit CLI option, but it's just a workaround. I hope it will be fixed soon.

[j]

This was an annoying for us as well.

I noticed if you just raise the timeout and give the DNS time to close, it won't emit this error, so another potential workaround?

yarn test --testTimeout=10000

[LinusU]

I'm seeing this as well, seems to have started when I upgraded from Jest 25 to 26 and switched to the jest-circus runner.

[ShivamJoker]

I am also having the same issue please fix this now its been there from long time.

[dahlmo]

Same symptoms here w/Jest v.26.0.23 and node v14.15.0. The minimal repro provided by @CatsMiaow (https://github.com/CatsMiaow/jest-issues-9982) seems to validate the issue on my end.

[seahindeniz]

Same happens here

repo https://github.com/seahindeniz/jest-dnschannel-issue

[joshkel]

After looking into this, I think the DNSCHANNEL is harmless. If I'm understanding the code correctly, the Resolver class from Node.js's dns module automatically creates one as part of its ChannelWrap C++ class that it uses to wrap the c-ares resolver library. (See here and here.)

However:

• Node doesn't seem to expose any way for callers to free those wrappers (at least, not for the dns module's default resolver), which suggests that the Node.js developers think they shouldn't cause a problem.
• They don't seem to actually prevent Jest from exiting: if I run the test cases from https://github.com/CatsMiaow/jest-issues-9982 or https://github.com/seahindeniz/jest-dnschannel-issue without --detectOpenHandles, then Jest exits quickly and without error.

Based on that, I'm thinking that DNSCHANNEL is a false positive: it's harmless, it's not actually keeping Jest from exiting, and if Jest is kept from exiting, it's because of some other resource (which may not be showing up correctly for various reasons - see, e.g., #11464).

[seahindeniz]

Yes, it's probably a false positive one, but I believe it's interrupting the development process. The logs are too annoying, and it eats too much line from the terminal and leads us to scroll up every time.

I think I've faced this issue after upgrading the Jest from v26.6.3 to v27.0.1

[Mr0grog]

@joshkel yeah, I think you’re correct about DNSCHANNEL — it’s also explicitly marked as a weak reference in the Node.js source (just a couple lines after one of the ones you linked), so Jest probably shouldn’t track it. There’s actually an explicit block of code for this kind of thing (async stuff that shouldn’t prevent the process from exiting or be tracked), but DNSCHANNEL just isn’t included there and probably should be: https://github.com/facebook/jest/blob/2cb20e945a26b2c9867b30b787e81f6317e59aa1/packages/jest-core/src/collectHandles.ts#L65-L73

(I made some improvements to this area of the codebase just before the Jest 27 release, so I’m at least a little familiar with what’s going on there. 🙂)

[github-actions]

This issue 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.