cypress: ECONNRESET on Chrome/Chromium 117.0.5851.0 when using Cypress <12.15.0 or passing`--headless=old` in browser launch options

If anyone is seeing this issue on Cypress versions 12.14.0 and earlier and can use the --headless=new flag (which is the default from Cypress version 12.15.0 and afterward), you can tell Chrome to use the option by adding the following to your setupNodeEvents:

setupNodeEvents(on, config) {
  on('before:browser:launch', (browser, launchOptions) => {
    if (browser.name === 'chrome' && browser.isHeadless) {
      launchOptions.args = launchOptions.args.map((arg) => {
        if (arg === '--headless') {
          return '--headless=new'
        }
  
        return arg
      })
    }
  
    return launchOptions
  })
}

We’re investigating this issue currently.

Just clarifying the issue and who it’s affecting:

• There’s an issue where users using Chrome 117.0.5851.0+ will see an ECONNRESET error when running via cypress run in all OS’s if they are using:
  • Cypress version <12.15.0. The--headless=new flag was introduced and is passed by default in 12.15.0.
  • Cypress version 12.15.0+ and manually passing a --headless=old flag.

Root cause:

• This is an issue introduced by Chrome in version 117.0.5851.0. We’ve opened an issue with them detailing the issue and are awaiting their response.

Available workarounds:

• Downgrade Chrome to Chrome 116 (or technically Chrome 117.0.5849.0).
• Update to use Chrome Canary 119.0.6017.1
• Upgrade to Cypress 12.15.0 if on an earlier version.
• For users that cannot upgrade to Cypress 12.15.0, they can pass the --headless=new flag manually as described here.
• Remove passing --headless=old from your test run.
• Pass --headed to your test run (note, this may change the behavior of tests).

If you are encountering issues with any of these workarounds, please detail those issues and open an issue in GitHub. There are some users reporting hanging with the headless=new flag in Cypress, but we don’t have a way to reproduce that yet and would love to fix that.

We don’t expect Chrome to support the --headless=old flag forever, so fixing issues with the --headless=new flag are high priority to us.

I can confirm Google Chrome / Chromium Linux 117.0.5938.132 no longer has this issue

On Windows/Mac it is slowly rolling out

GitHub is now rolling out runner-images 20230915 - 20230918 with Chrome, Chromium & Edge 117 version browsers. Until the roll-out has completed an old version image or a new version image is randomly triggered. It is also possible to see a workflow using different versions for different jobs in the same workflow where there is more than one job triggered.

So it is likely that default GitHub Actions workflows with Cypress < version 12.15.0 testing against any of the Chromium family browsers will start seeing failures.

For workarounds, see previous comments.

Edit: All rollouts updating Chromium family browsers (including Chrome) to 117 have reached 100%. If you have a GitHub workflow running with default settings you will certainly be picking up this version. In the meantime a new set of rollouts has started which update to a later 117 patch level e.g. on ubuntu-22.04 from 117.0.5938.88 to 117.0.5938.92. (Only macOS 13 beta is lagging behind.)

I was able to reproduce the issue outside of Cypress in standalone Chrome. I’ve logged a Chromium bug.

@jennifer-shehane

• Chromium team fixed the issue
• Fix is currently in Chrome Canary 119 and will be in the next dev/beta/stable build

Same issue here, had to downgrade to 116 version to make it works

GitHub is preparing to roll out browser fixes, for example through:

• https://github.com/actions/runner-images/releases/tag/ubuntu22/20231001.1

So it is likely that default GitHub Actions workflows with Cypress < version 12.15.0 testing against any of the Chromium family browsers will start seeing failures.

As further confirmation: I began seeing this exact failure case today with GitHub Actions using Cypress 12.5.1. It would happen on occasion, happening more and more throughout the day, I imagine as the newer Actions rolled out.

Upgrading to Cypress 12.17.0 seems to have fixed it.

According to https://storage.googleapis.com/chromium-find-releases-static/441.html#441de2f21f1d43a751b5f87f5240252654135a76 the fix is now in the pipeline for 117 (as commit https://github.com/chromium/chromium/commit/cea8ca443cf76ceb3186e544b332a1b8bf3f3571) and for 118 (as commit https://github.com/chromium/chromium/commit/83e7d98faed68c98737f52ef021624256adc63a3). It’s already available in the 119 Canary version.

I understand from your post in Chromium bug 1483163 that you were able to test a Canary release successfully. Is that correct? Which exact build / operating system did you use?

Yes, 119.0.6016.0 Windows x64

I think the title of this issue should be changed to include Chromium since Chrome is not the only chromium browser with this issue

Hi! For 12.4.0 cypress and Chrome 117 the following solution works:

cypress.config.ts

setupNodeEvents(on, config) {
            on(
                'before:browser:launch',
                (browser: Browser, launchOptions: BrowserLaunchOptions) => {
                    if (browser.name === 'chrome' && browser.isHeadless) {
                        const headlessIndex =
                            launchOptions.args.indexOf('--headless');
                        if (headlessIndex > -1) {
                            launchOptions.args[headlessIndex] =
                                '--headless=new';
                        }
                    }
                    return launchOptions;
                },
            );
            return require('./cypress/plugins/index.ts')(on, config);
        },

this solution doesn’t work for me:

launchOptions.args = launchOptions.args.map((arg) => {
        if (arg === '--headless') {
          return '--headless=new'
        }

@MikeMcC399 Thanks, updated my comment to be clearer.

@mschile can you pin this issue?

This is how I explained it in the bug report comments

I tested on my Windows machine with --headless and it has the same issue as --headless=old, I’ll make a new comment on the bug report

Thank you @alexsch01 for confirming and following up in the Chromium bug report! I would consider --headless not working as a higher priority regression than if just --headless=old didn’t work, but I guess that will be up to the Chromium team to prioritize.

@MikeMcC399 I tested on my Windows machine with --headless and it has the same issue as --headless=old, I’ll make a new comment on the bug report