cypress: ESOCKETTIMEDOUT error

For me I had a webserver which failed if it could not find the “Accept-Encoding” header.

Fixed with :

cy.visit(url, {
  headers: {
    "Accept-Encoding": "gzip, deflate"
  }
})

We’ve fixed the problem by adding a request header (Connection: "Keep-Alive") to the visit command.

This also happens to me when testing inside our CI environment(codeship basic). There is no problem with local environment, but on CI, ESOCKETTIMEDOUT occurs about half of the time, when visiting an url using cy.visit().

Is this a problem of our CI server(i.e., too slow)? Or, just changing timeout configuration is enough?

(UPDATE) I doubled pageLoadTimeout only on CI and it works as expected. But I’m still not sure this is the right solution to the problem.

For me I had a webserver which failed if it could not find the “Accept-Encoding” header.

Fixed with :

cy.visit(url, {
  headers: {
    "Accept-Encoding": "gzip, deflate"
  }
})

Thank you, @thomasleveil ! This was driving me crazy and your suggestion worked like a charm.

Today, I’m seeing this error while running Charles Proxy to forward our prod domain to localhost:9002. For me it happens consistently on the same test during the login process… but if I run a single spec instead of all tests, it happens in a different place (after a certain number of requests have been made maybe)?

Perhaps it is some inconsistency with the proxy in different environments?

If I run it against our prod environment without going through Charles Proxy, there are no issues whatsoever.

I made some progress by bumping up the UV_THREADPOOL_SIZE but not much. I added process.env.UV_THREADPOOL_SIZE = 64; to the beginning of cypress/support/index.js which consistently allows more tests to run before connections stop working and Cypress ultimately crashes.

Once the timeouts start, it doesn’t matter if I stop and restart a spec. As long as the same node process (that started Cypress) is still running, all connections fail.

node v12.8.1 cypress v3.4.1

I spoke too soon. This worked for me locally, but when I ran the same test in a CodeBuild job, I got the ESOCKETTIMEDOUT error again, despite having "Accept-Encoding": "gzip, deflate" in the headers.

I’m getting a similar issue running this locally against a dockerized django app. My cypress service is linked to the app.

cypress:
  volumes:
    - ./app:/app/app
    - ./cypress:/app/cypress
    - ./cypress.json:/app/cypress.json
    - ./wait-for-it.sh:/app/wait-for-it.sh
  build: ./cypress.Dockerfile
  container_name: cypress
  environment:
    - CYPRESS_baseUrl=http://app:8000
  links:
    - app
  command: /app/wait-for-it.sh app:8000 -t 30 -- npx cypress run --spec='./cypress/integration/**'

I get the following errors:

The request we sent was:

Method: GET
URL: http://app:8000/status/

-----------------------------------------------------------

Common situations why this would fail:
  - you don't have internet access
  - you forgot to run / boot your web server
  - your web server isn't accessible
  - you have weird network configuration settings on your computer

The stack trace for this error is:

RequestError: Error: ESOCKETTIMEDOUT
    at new RequestError (/root/.cache/Cypress/3.1.4/Cypress/resources/app/packages/server/node_modules/request-promise-core/lib/errors.js:14:15)
    at Request.plumbing.callback (/root/.cache/Cypress/3.1.4/Cypress/resources/app/packages/server/node_modules/request-promise-core/lib/plumbing.js:87:29)
    at Request.RP$callback [as _callback] (/root/.cache/Cypress/3.1.4/Cypress/resources/app/packages/server/node_modules/request-promise-core/lib/plumbing.js:46:31)
    at self.callback (/root/.cache/Cypress/3.1.4/Cypress/resources/app/packages/server/node_modules/request/request.js:185:22)
    at emitOne (events.js:115:13)
    at Request.emit (events.js:210:7)
    at ClientRequest.<anonymous> (/root/.cache/Cypress/3.1.4/Cypress/resources/app/packages/server/node_modules/request/request.js:819:16)
    at Object.onceWrapper (events.js:314:30)
    at emitNone (events.js:105:13)
    at ClientRequest.emit (events.js:207:7)
    at Socket.emitTimeout (_http_client.js:722:34)
    at Object.onceWrapper (events.js:314:30)
    at emitNone (events.js:105:13)
    at Socket.emit (events.js:207:7)
    at Socket._onTimeout (net.js:402:8)
    at ontimeout (timers.js:469:11)
    at tryOnTimeout (timers.js:304:5)
    at Timer.listOnTimeout (timers.js:264:5)

It’s not consistently reproducible but I also encounter this issue as well, on several specs.