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
localhost URL not accessible after cy.request on server #25397
Comments
@nicolas-marien thanks for the repo. I cloned it, installed dependencies and ran
which launched Cypress, but I didn't see any client or server running on port Am I missing something? |
@astone123 Oh sorry! I forgot to add the start command to run everything 🙄 |
@nicolas-marien thanks for clarifying. I was able to run the application but I'm not seeing the same error message. The test passes for me |
Thank you @astone123 for your answer. |
@nicolas-marien I was able to reproduce your issue by using Node18. With Node16, the e2e test works fine. There was a DNS change between Node16 and Node18 (issue) that you might be running into. I'll keep investigating to see where the problem lies and if there is a workaround for you. |
Can you try adding To be explicit, this is the update I made: "serve": {
"executor": "@nrwl/webpack:dev-server",
"defaultConfiguration": "development",
"options": {
"buildTarget": "client:build",
"hmr": true,
"host": "127.0.0.1" <----
}, Still investigating if there is an issue on our side. Cypress will warn the user it can't connect to the provided Edit: After investigating, it looks like the issue is due to Nx's use of |
I closed this prematurely, I'm now seeing some buggy behavior based on your reproduction where a request made to your backend before visiting is causing Cypress to lock onto the ipv4 range (hence the 127.0.0.1 connection refused). Shifting the request to be after the visit doesn't display this behavior. I'm working on a very simple reproduction. |
I've created a simple reproduction here. The README explains the bug in detail. My understanding of the bug is:
If you move the request to after the visit, everything works fine. Also, if Cypress is allowed to visit before sending the request (by commenting out the request), adding the request back in works fine. There must be some server state being set from the initial request that influences subsequent visit requests. |
Thank you @ZachJW34 for your detailed answers. |
@nicolas-marien your workflow is totally valid. I've routed this to the e2e team and they will prioritize accordingly. |
@ZachJW34 thanks for the feedback. |
Are there any updates on this issue? Thanks. |
Same issue here I was using node 18.10 and cypress 12.9.0, I downgraded the node version to 16.13.2 and that fixed the issue. |
We are unable to upgrade to node 18 due to this issue |
For me instructing the bundle server (in my case vite) to explicitly use host '127.0.0.1' fixed the issue. |
This was solving the issue also on my dev-env. Using v12.9.0 |
I have set default nvm version from 16 to 20 with |
- This PR adds settings pages to the organization and user organization pages. - Admin users can edit their preferences, billing, and organization type - Updated cypress version to address bug cypress-io/cypress#25397
- This PR adds settings pages to the organization and user organization pages. - Admin users can edit their preferences, billing, and organization type - Updated cypress version to address bug cypress-io/cypress#25397
- This PR adds settings pages to the organization and user organization pages. - Admin users can edit their preferences, billing, and organization type - Updated cypress version to address bug cypress-io/cypress#25397
- This PR adds settings pages to the organization and user organization pages. - Admin users can edit their preferences, billing, and organization type - Updated cypress version to address bug cypress-io/cypress#25397
- This PR adds settings pages to the organization and user organization pages. - Admin users can edit their preferences, billing, and organization type - Updated cypress version to address bug cypress-io/cypress#25397
- This PR adds settings pages to the organization and user organization pages. - Admin users can edit their preferences, billing, and organization type - Updated cypress version to address bug cypress-io/cypress#25397
- This PR adds settings pages to the organization and user organization pages. - Admin users can edit their preferences, billing, and organization type - Updated cypress version to address bug cypress-io/cypress#25397
- This PR adds settings pages to the organization and user organization pages. - Admin users can edit their preferences, billing, and organization type - Updated cypress version to address bug cypress-io/cypress#25397
- This PR adds settings pages to the organization and user organization pages. - Admin users can edit their preferences, billing, and organization type - Updated cypress version to address bug cypress-io/cypress#25397
- This PR adds settings pages to the organization and user organization pages. - Admin users can edit their preferences, billing, and organization type - Updated cypress version to address bug cypress-io/cypress#25397
I get this error after upgrading Node from 16 to 18 or 20. I'm not even using A workaround when using Vite is hinted at here: https://vitejs.dev/config/server-options.html#server-host
or set (Adding the code |
This issue is painful to me, see my test results below. Test machines:
Test project:
Test cases:
Conclusion:
|
Are you able to test on Node.js This is not to invalidate your issue in any way, but it might possibly be a workaround.
|
Thanks, @MikeMcC399, I did some quick checks on Linux with Node v20.9.0, my test case results did not change, even the IPv6 issue is still the same. |
News about this? We are using Gatsby v5, and Node 18 is a requirement. Things I've tried:
Considering this bug is almost a year old, I'd like to know if there is any workaround I'm missing. |
You just have to start your dev server / app on a host with an ipv4 address. In my case |
Well this was an odd one... The React frontend could interact with the Python backend using localhost when the Analyze button was click. Cypress performing the same button click did not trigger a call to the Python API. My initial fix was changing the url invoked by the button click to `127.0.0.1` instead of `localhost`, but the IP didn't sit right with me. I tried several other fixes, but [enabling `ipv4first`](cypress-io/cypress#25397 (comment)) is the only one that worked. This is due to a fairly recent change to NodeJS documented [here](https://nodejs.org/api/dns.html#dnssetdefaultresultorderorder) and further explained [here](https://nodejs.org/api/dns.html#dnslookuphostname-options-callback) as setting `verbatim` to false in dns lookup, which prioritized ipv4 addresses over ipv6: > verbatim [<boolean>](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures#Boolean_type) When true, the callback receives IPv4 and IPv6 addresses in the order the DNS resolver returned them. When false, IPv4 addresses are placed before IPv6 addresses. Default: true (addresses are not reordered).
I just run into this issue (Cypress v12.17.4 with node v18.16.1). Before I found this workaroud in this issue-thread here I had another one (Working with proxy and default "localhost"-setting"):
|
My workaround for anyone interested I had a few personal requirements:
go to your support file I figured, since the cause for the issue is a cy.request() (and it was still an issue, after I replaced my login logic with fetch()), we can just do a fetch before all tests run. Of course you can use a hardcoded url for this Give me a thumbs up, if it works for you as well. I will report back, If I improve or change anything or if it stop working :C |
- [x] do not use deleteTestUser at end of tests to clean up state (it should also not use the ui with cy.) - [x] use cy.task('db:reset') to clean up state before tests when required - [x] do not use createTestUser before tests to login (its using the UI as well, which should not be) - [x] use minimal login implementation as command (using fetch and storing the response (access token) into localStorage - known issue at Cypress cypress-io/cypress#25397 (comment) - workaround as descibred in the cypress comment. (triggering a fetch to the spa, before all tests run)
This resolved the issue for me, quick and easy without having to change the host. |
@RobinMeow solution worked like a charm. Thanks! |
I was using Node 20.10.0 and had to downgrade to Node 16.13.2. I can confirm that this is a bug. |
what node version ? |
This is what worked for me. Thanks. ETA: This works only when running the target headless. I still get the issue when using ETA #2: This only worked locally for me. Totally flopped in our gitlab pipeline |
Current behavior
Hello 👋
We are trying to integrate Cypress but we run into an issue. Cypress tells us that our frontend is not reachable.
The client runs on port 4200 and the server on port 3333.
We are working in an monorepo managed by NX. The client is a basic React application, and the server is a NestJS application.
First we make a call to our server using
cy.request
and then we usecy.visit
.The
cy.visit
fails (see screenshot attached) telling is that the connection is refused.When opening
http://localhost:4200
on a browser behaves as intended.When we change the server URL to point to
127.0.0.1
things work fine (but cookies are broken, and we want cookie 🍪).I put together a bare bone repository where things can be reproduced: https://github.com/nicolas-marien/nx-cypress-localhost-issue
Please find attached the output of
DEBUG=cypress:* NODE_DEBUG=request y nx e2e client-e2e --watch
I do not have any corporate proxy.
Thank you for your help.
Desired behavior
The
cy.visit(/)
call should open my client.Test code to reproduce
Start client and server using
yarn nx run-many --target=serve
Run
yarn nx e2e client-e2e --watch
and select the only spec file.Cypress Version
12.3.0
Node version
18.10.0
Operating System
MacOS 12.6.1 (also happens on Ventura)
Debug Logs
Other
No response
The text was updated successfully, but these errors were encountered: