Failed to find a DNS-record for the resource at "localhost" after upgrading Node version to 18

[vlad-dargel]

What is your Scenario?

My project app was running on Nodejs v14.17.1. Then it was updated to Node 18.14.2 and now TestCafe (v2.6.2) fails to load the pages. The only thing I can see on the network requests is that the document request returns a 302 that redirects to the about page

I have tried downgrading the TestCafe version didn't work, other errors appear.

Also I'm not considering it as it's experimental. I have tried setting quarentine mode, the --hostName, nothing of this worked. Also obvious to say, if I open the URL it loads perfectly on the browser outside TestCafe.

If I use --native-automation then tests are running, but I have many tests with 'Multiple Browser Windows' so this doesn't suit me.

What is the Current behavior?

Failed to load the page at "http://localhost:8080/".
      Increase the value of the "pageRequestTimeout" variable, enable the "retryTestPages" option, or use quarantine mode to perform additional attempts to execute      
      this test.
      You can find troubleshooting information for this issue at "https://go.devexpress.com/TestCafe_FAQ_ARequestHasFailed.aspx".

Failed to find a DNS-record for the resource at "http://localhost:8080/".

What is the Expected behavior?

What is your public website URL? (or attach your complete example)

What is your TestCafe test code?

--

Your complete configuration file

No response

Your complete test report

No response

Screenshots

No response

Steps to Reproduce

TestCafe version

2.6.2

Node.js version

18.14.2

Command-line arguments

chrome:headless --cache --allow-insecure-localhost --ignore-certificate-errors

Browser name(s) and version(s)

Chrome

Platform(s) and version(s)

Windows/Linux

Other

No response

[omacranger]

Sounds like you're running into this.

You can usually do something like below in your testcafe runner (if you're using JS) to work around it. If you're using CLI, you may be able to leverage the node cli option --dns-result-order=ipv4first instead.

const dns = require('dns');

dns.setDefaultResultOrder('ipv4first');

[vlad-dargel]

--dns-result-order=ipv4first

thanks, but it doesn't work, I get the same error Failed to find a DNS-record for the resource at "http://localhost:8080/".

[miherlosev]

Hi @vlad-dargel,

It's not a TestCafe issue. It's a breaking change in Node.js, which breaks the DNS address resolution mechanism.
The simplest way to fix it is changing the host name in a test page's URLs from localhost to 127.0.0.1.

[vlad-dargel]

Hi @vlad-dargel,

It's not a TestCafe issue. It's a breaking change in Node.js, which breaks the DNS address resolution mechanism. The simplest way to fix it is changing the host name in a test page's URLs from localhost to 127.0.0.1.

Yes, I tried to use '127.0.0.1' instead of 'localhost' but it doesn't help too

[miherlosev]

If you open the tested URL http://localhost:8080/ or http://127.0.0.1:8080/ in the browser (without TestCafe), does it work correctly?

[MattMcFarland]

@miherlosev I've been using testcafe for about a year with great success and my team has ran into the same issue after we updated our project from node 14 to node 18. What we found is that testcafe works fine when using externally hosted domains, but localhost (or using 127.0.0.1, or an alias specified in etc/hosts) yields the same error OP brought up.

Our setup is not anything special, its just a gatsby js site we run on localhost during local development. When testing locally, we can access the site just fine going to localhost with our browser or with curl etc. The only thing that appears to struggle accessing it is testcafe. We also use testcafe against staging/test environments which are hosted externally, and testcafe has no problem accessing those. It only fails when we try to make it access a site that is running on the same machine.

The good news is when using --experimental-proxyless the problem goes away and the tests execute against localhost! :) I'm not sure if this is a stable solution but it did unblock us for the time being. Rolling back to node 14 resolves the issue as well, but we of course don't want to do that.

Because an IP address does not need a DNS lookup, then I assume the "DNS ERROR" is custom made and the real error was caught and swallowed so a more human readable error message could be displayed. It's prob not a DNS lookup issue, but it's throwing in a try/catch that assumes it is. If that is the case, is there a way to get testcafe to output the error object that was caught? That could hold the answer as to what is causing this.

It also might be OS related and if so, we're running on OSX if that helps. I hope this does help track this down, lmk if any questions

[aleks-pro]

Hello @MattMcFarland ,

The good news is when using --experimental-proxyless the problem goes away and the tests execute against localhost! :) I'm not sure if this is a stable solution but it did unblock us for the time being.

Starting with testcafe v3.0.0, the Native Automation mode aka Proxyless is enabled by default. Currently, it has several limitations, but if they do not affect your tests, you can use this mode to overcome the issue.

[yasinkocak]

Any news of this issue, i get the same error

[PavelMor25]

Hello @yasinkocak,

Native automation must fix the issue. If you can reproduce the issue using native automation mode, please create a separate ticket using this template.