-
Notifications
You must be signed in to change notification settings - Fork 671
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failed to find a DNS-record for the resource at "localhost" after upgrading Node version to 18 #7753
Comments
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
|
thanks, but it doesn't work, I get the same error |
Hi @vlad-dargel, It's not a TestCafe issue. It's a breaking change in Node.js, which breaks the DNS address resolution mechanism. |
Yes, I tried to use '127.0.0.1' instead of 'localhost' but it doesn't help too |
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? |
@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 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 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 |
Hello @MattMcFarland ,
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. |
Any news of this issue, i get the same error |
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. |
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?
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
The text was updated successfully, but these errors were encountered: