cypress icon indicating copy to clipboard operation
cypress copied to clipboard

'Cypress could not verify that this server is running' error with baseUrl in component test after updating to v13

Open nik2202 opened this issue 2 years ago • 29 comments

Current behavior

In the UI it displays the warning "cannot connect base url" image But here it is possible to ignore and execute the tests.

With the CLI it fails: image

Desired behavior

Before I updated it to version 13 it was working and it was not required to define the baseUrl for component tests. And the command npx nx component-test core-tables works without problems

Test code to reproduce

import { defineConfig } from 'cypress';
import { nxComponentTestingPreset } from '@nrwl/angular/plugins/component-testing';

export default defineConfig({
  component: {
    ...nxComponentTestingPreset(__filename),
    video: false,
    reporter: '../../../node_modules/cypress-multi-reporters',
    reporterOptions: {
      configFile: 'reporter.json'
    },
    screenshotsFolder: '../../../dist/cypress/libs/reports/mochawesome/screenshots/about'
  }
});

Cypress Version

13.2.0

Node version

v18.15.0

Operating System

Windows 10

Debug Logs

> nx run core-tables:component-test

DevTools listening on ws://127.0.0.1:59615/devtools/browser/3a1d1242-0013-46a8-9bd2-6d4ea7994825
Browserslist: caniuse-lite is outdated. Please run:
  npx update-browserslist-db@latest
  Why you should do it regularly: https://github.com/browserslist/update-db#readme
- Generating browser application bundles (phase: setup)...
Cypress could not verify that this server is running:

  > http://localhost:8080

We are verifying this server because it has been configured as your baseUrl.

Cypress automatically waits until your server is accessible before running tests.

We will try connecting to it 3 more times...
We will try connecting to it 2 more times...
We will try connecting to it 1 more time...

Browserslist: caniuse-lite is outdated. Please run:
  npx update-browserslist-db@latest
  Why you should do it regularly: https://github.com/browserslist/update-db#readme
Cypress failed to verify that your server is running.

Please start this server and then run Cypress again.

Other

nx version: 15.7.2

nik2202 avatar Oct 06 '23 11:10 nik2202

What is the nx run core-tables:component-test script running? Are you passing the --component flag to cypress run?

Which version did you upgrade from?

jennifer-shehane avatar Oct 06 '23 15:10 jennifer-shehane

What is the nx run core-tables:component-test script running? Are you passing the --component flag to cypress run?

Which version did you upgrade from?

Previous version was 12.17.1

My project is an Angular nx monorepo. It is the basic command from nx to execute cypress component tests: https://nx.dev/recipes/cypress/cypress-component-testing#watching-for-changes-headed-mode

project.json

"component-test": {
      "executor": "@nrwl/cypress:cypress",
      "options": {
        "cypressConfig": "libs/core/tables/cypress.config.ts",
        "testingType": "component",
        "skipServe": true,
        "devServerTarget": "demo-app:build"
      }
    }

nik2202 avatar Oct 06 '23 16:10 nik2202

But even with the cypress command I have the same output:

libs\core\tables> npx cypress run --component


DevTools listening on ws://127.0.0.1:64440/devtools/browser/9ba17c02-7320-4b6f-abcb-a666f50afe07
[34656:1006/183419.667:ERROR:display_layout.cc(551)] PlacementList must be sorted by first 8 bits of display_id
- Generating browser application bundles (phase: setup)...
Cypress could not verify that this server is running:

  > http://localhost:8080

We are verifying this server because it has been configured as your baseUrl.

Cypress automatically waits until your server is accessible before running tests.

We will try connecting to it 3 more times...
We will try connecting to it 2 more times...
We will try connecting to it 1 more time...

nik2202 avatar Oct 06 '23 16:10 nik2202

I am also getting this after upgrading to v13. If I replace localhost with its IP address in the baseUrl config, then it works as normal, but either ought to work.

MetRonnie avatar Oct 12 '23 15:10 MetRonnie

I am also getting this after upgrading to v13. If I replace localhost with its IP address in the baseUrl config, then it works as normal, but either ought to work.

@MetRonnie Could you share your config? Because for me it was not working

nik2202 avatar Oct 13 '23 06:10 nik2202

@niklashauschel https://github.com/cylc/cylc-ui/blob/2549d65663fe9564f371e7805700eb9ec47295f1/cypress.config.js#L18

MetRonnie avatar Oct 13 '23 09:10 MetRonnie

Hmm does not work. @jennifer-shehane The question is why it is required to have an e2e setup even if I just have component tests. Before it was working

nik2202 avatar Oct 17 '23 09:10 nik2202

(I get the "could not verify this server is running" message for both E2E and component tests, when I didn't before. It causes cypress run E2E tests to fail but cypress open E2E still works)

MetRonnie avatar Oct 17 '23 10:10 MetRonnie

Possibly related to #25397?

MetRonnie avatar Oct 23 '23 15:10 MetRonnie

I'm seeing a similar issue, @MetRonnie Thanks, updating the baseUrl to IP worked for e2e tests. But component testing doesn't have the property exposed in config and cannot be overridden.


interface ComponentConfigOptions<ComponentDevServerOpts = any> extends Omit<CoreConfigOptions, 'baseUrl' | 'experimentalStudio'> {
    devServer: DevServerFn<ComponentDevServerOpts> | DevServerConfigOptions
    devServerConfig?: ComponentDevServerOpts
    /**
     * Runs all component specs in a single tab, trading spec isolation for faster run mode execution.
     * @default false
     */
    experimentalSingleTabRunMode?: boolean
  }

Rahul-Todupunoori avatar Oct 27 '23 13:10 Rahul-Todupunoori

I have the same issue after upgrading from Cypress 12.7.2 to 13.6.2. When I run the following command on Linux, I get:

> cypress run --component --browser chromium


DevTools listening on ws://127.0.0.1:43411/devtools/browser/f036190f-b6d2-4bbf-a3b3-512953f97dbc
[356314:0109/140456.248459:ERROR:object_proxy.cc(590)] Failed to call method: org.freedesktop.portal.Settings.Read: object_path= /org/freedesktop/portal/desktop: org.freedesktop.portal.Error.NotFound: Requested setting not found
(node:356503) ExperimentalWarning: Custom ESM Loaders is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
(node:356503) ExperimentalWarning: The Node.js specifier resolution flag is experimental. It could change or be removed at any time.
vite:istanbul> Sourcemaps was automatically enabled for code coverage to be accurate.
 To hide this message set build.sourcemap to true, 'inline' or 'hidden'.
Cypress could not verify that this server is running:

  > http://localhost:5173

We are verifying this server because it has been configured as your baseUrl.

Cypress automatically waits until your server is accessible before running tests.

We will try connecting to it 3 more times...
We will try connecting to it 2 more times...
We will try connecting to it 1 more time...

Cypress failed to verify that your server is running.

Please start this server and then run Cypress again.

The cypress open --component command would also show me a warning about the base URL, but at least the tests can still be executed. Edit: If i pressed Try again, the warning would not go away until I selected a browser. Once the browser is opened, the warning disappeared when pressing Try again.

Interestingly enough, I can run component tests inside a cypress/browsers Docker image ... I don't know what the difference is yet.

rkrisztian avatar Jan 09 '24 13:01 rkrisztian

I found a clue! In /etc/hosts, if I comment out the line for ::1, component tests work:

#::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
127.0.0.1	localhost.localdomain	localhost myhostname

Then this issue is now similar to https://github.com/cypress-io/cypress/issues/25397, except here we don't even use a base URL, and nothing I tried so far helps as a workaround.

rkrisztian avatar Jan 10 '24 08:01 rkrisztian

@jennifer-shehane : I also reported this issue in https://github.com/cypress-io/cypress/issues/27967. I dont find any other workaround to resolve this issue as well. :(

mdlkumaran avatar Feb 09 '24 14:02 mdlkumaran

After few days of reading the Cypress source code and testing on our Azure server, I found that if ENV-variable HTTP_PROXY or HTTPS_PROXY is set, the server verification would fail.

Row 59 in server/lib/util/ensure-url. ts function isListening:

export const isListening = (urlStr: string) => {
  // takes a urlStr and verifies the hostname + port is listening
  let { hostname, protocol, port } = url.parse(urlStr)

  if (port == null) {
    port = protocol === 'https:' ? '443' : '80'
  }

  if (process.env.HTTP_PROXY) { <-- HERE
    // cannot make arbitrary connections behind a proxy, attempt HTTP/HTTPS
    // For some reason, TypeScript gets confused by the "agent" parameter
    // and required double ts-ignore to allow it on local machines and on CI
    // @ts-ignore
    return rp({
      url: urlStr,
      // @ts-ignore
      agent,
      proxy: null,
    })
    .catch({ name: 'StatusCodeError' }, () => {}) // we just care if it can connect, not if it's a valid resource
  }

  return connect.getAddress(Number(port), String(hostname))
}

Zypzone avatar May 13 '24 12:05 Zypzone

@jennifer-shehane: I think there is a need to verify that the NO_PROXY settings are respected everywhere in the source code

Zypzone avatar May 23 '24 06:05 Zypzone

The issue is reproducible as well with Cypress version: 13.9.0

cronwel91 avatar May 24 '24 11:05 cronwel91

Add this line to your etc/hosts and maybe it will resolve your problem :)

127.0.0.1 localhost

NassrEML avatar May 31 '24 13:05 NassrEML

Add this line to your etc/hosts and maybe it will resolve your problem :)

127.0.0.1 localhost

I have tried this already and unfortunately did not help.

cronwel91 avatar May 31 '24 15:05 cronwel91

Any update on this @jennifer-shehane ? This issue has kept us from using the awesome cypress component testing and restricted us to still use only the e2e testing. Any eyes on this is greatly appreciated. Thanks

mdlkumaran avatar Jul 25 '24 23:07 mdlkumaran

Same here, do you have any updates? Sometimes it works (when the backend-Server spools up quickly), sometimes not. Would be nice if those end-2-end test would run a bit more reliable

AeroSecGeek avatar Aug 12 '24 02:08 AeroSecGeek

I am also getting this after upgrading to v13. If I replace localhost with its IP address in the baseUrl config, then it works as normal, but either ought to work. It worked totally fine! Thanks

kasra-noorbakhsh avatar Aug 12 '24 09:08 kasra-noorbakhsh

I was going to look into this because I thought it was easily reproducible, but in trying to reproduce it - I can't reproduce it with the information provided. I've been running cypress run --component and cypress open --component and I don't see these errors.

Can someone provide an example or explain the other pieces needed to reproduce?

My cypress.config.js:

const { defineConfig } = require("cypress");

module.exports = defineConfig({
  e2e: {
    baseUrl: "http://localhost:3000",
    setupNodeEvents(on, config) {},
  },

  component: {
    devServer: {
      framework: "react",
      bundler: "webpack",
    },
  },
});

jennifer-shehane avatar Aug 14 '24 19:08 jennifer-shehane

@jennifer-shehane Yes I can try to provide an example.

I use cypress for e2e tests against a web application. I run Cypress in the Pipeline against a fully built App Container, which connects to a PostgreSQL Database Container. The App Container contains a Spring Boot App with the React Application in the static folder.

My cypress.config.ts:

import { defineConfig } from 'cypress'

export default defineConfig({
  e2e: {
    baseUrl: 'http://localhost:5173',
    setupNodeEvents(on, config) {
      // implement node event listeners here
    },
  },
})

In the Pipeline, the App Container is built and thereafter the e2e tests are executed, Jenkinsfile:

stage('E2E tests'){
        environment{
            def currentDir = sh(returnStdout: true, script: 'pwd').trim()
            VOLUME_DIR = currentDir.replace('/var/jenkins_home', '/volume2/docker/enterprise/jenkins')
          }
          steps{
              script{
                  try{
                      sh 'docker-compose up --exit-code-from cypress'
                  }
                  catch(Exception e){
                      error("At least one e2e test failed: ${e.message}")
                  }
                  finally{
                      sh 'docker-compose down'
                  }
              }
          }
        }

And the docker-compose.yml:

version: '3'
services:
  app-service:
    image:app:${APP_VERSION}
    depends_on:
      - database
    command: ['--spring.profiles.active=e2e']

  cypress:
    image: cypress/included:13.6.3
    volumes:
      - ${VOLUME_DIR}/app-ui:/e2e
    depends_on:
      - app-service
    working_dir: /e2e
    command:
      [
        'cypress',
        'run',
        '--browser',
        'electron',
        '--config',
        'baseUrl=http://app-service:8080',
      ]

  database:
    image: postgres:15.2
    environment:
      - POSTGRES_USER=app-service
      - POSTGRES_PASSWORD=end2endTest@App
      - POSTGRES_DB=app-user

So I override the baseUrl from the config with the docker-compose file. Since the Spring boot app has a database connected, the start of the application takes some time (database migrations scripts). Running the pipeline repeatedly, the e2e sometimes work, sometimes not. When they fail, the message Cypress could not verify that this server is running is displayed because obviously the app container has not completed the startup of the App.

AeroSecGeek avatar Aug 14 '24 19:08 AeroSecGeek

Can someone provide an example or explain the other pieces needed to reproduce?

@jennifer-shehane It might be setting HTTP_PROXY or HTTPS_PROXY environment variables? See this comment above: https://github.com/cypress-io/cypress/issues/27990#issuecomment-2107494691

MetRonnie avatar Aug 15 '24 08:08 MetRonnie

@MetRonnie I'm not able to reproduce this issue when also setting the HTTP_PROXY and HTTPS_PROXY environment variables either.

@AeroSecGeek This example you provided is functioning as intended. There will be an error if the server is not running when the e2e tests begin running. You need to ensure it is running before calling Cypress for e2e tests. This specific issue is about how this server running error displays when running COMPONENT tests - where this server is not required to run for CT tests and shouldn't be erroring at all.

We'll need a reproducible example/repo of the original issue in order to investigate.

jennifer-shehane avatar Aug 19 '24 14:08 jennifer-shehane

@jennifer-shehane I don't know if using

import dns from 'dns'
dns.setDefaultResultOrder('ipv4first')

might affect it. We are doing this in our vite config to workaround https://github.com/cypress-io/cypress/issues/25397

Not really a minimal example, but you could try cloning https://github.com/cylc/cylc-ui and running

$ yarn install
$ yarn test:component

https://github.com/cylc/cylc-ui/blob/master/cypress.config.cjs https://github.com/cylc/cylc-ui/blob/master/vite.config.js

MetRonnie avatar Aug 19 '24 18:08 MetRonnie

@MetRonnie I got this repo up and running. The CT tests run without displaying a warning for me around 'Cypress could not verify that this server is running'.

I commented out the dns.setDefaultResultOrder('ipv4first') line and there is still no warning. Is there an extra step I should take?

jennifer-shehane avatar Aug 21 '24 14:08 jennifer-shehane

@jennifer-shehane Hmm, not sure what else. I am on Node 20.16.0, don't know if there would be any difference at Node 22 if that's what you are on

MetRonnie avatar Aug 21 '24 14:08 MetRonnie

I think it is proxy related, as I cannot reproduce on my personal PC but can on my work machine

MetRonnie avatar Aug 27 '24 09:08 MetRonnie

we are facing similar issue while these tests on Jenkins using containers. For now we added a retry mechanism , retry has solved the problem , yet we are not able to figure out root cause .

scsannalli avatar Sep 16 '24 11:09 scsannalli