If we cannot connect to Chrome via RDP we should re-launch the browser

[bahmutov]

Cypress v4.20

Sometimes we randomly get "Failed to connect to Chrome" error, like this

Since the error is pretty random, I believe this is due to RDP port being blocked or some transient thing. We do retry to connect, allowing the browser to start, but seems in some cases the browser is completely unable to receive our connection.

I have come up with a way to simulate the situation in https://github.com/bahmutov/cypress-native-chrome-code-coverage-example/tree/change-rdp-port branch change-rdp-port. Its plugin replaces the RDP port Cypress wants with random number

// cypress/plugins/index.js
// on event 'before:browser:launch'
  // find how Cypress is going to control Chrome browser
  // and change the port number
  const rdp = 40000 + Math.round(Math.random() * 25000)
  console.log('plugin: new RDP port', rdp)
  // have to replace an item in the array without changing the reference
  launchOptions.args.forEach((arg, k) => {
    if (arg.startsWith('--remote-debugging-port')) {
      console.log('replacing "%s"', arg)
      launchOptions.args[k] = `--remote-debugging-port=${rdp}`
    }
  })

  console.log('updated browser arguments')
  console.log(launchOptions.args.join('\n'))

  return launchOptions

causing the same failure.

Proposal: in this case, we should kill the browser process, pick new RDP port and try again.

[jennifer-shehane]

You can recreate this if you open 2 instances of Cypress. Not sure it's relevant to what you're experimenting with, but it does annoy me. #5613

[flotwig]

Do you think this is a port collision issue, or what?

I think that this might not be the best idea because of how new browser processes interact with existing browser processes. In the case of #5613, relaunching the browser would open up a new window in the existing browser session each time the browser is relaunched, which would be pretty undesirable behavior imo.

[bahmutov]

Don’t we know the child browser process pid so we can kill it accurately before relaunching ?

…

Sent from my iPhone

On Mar 31, 2020, at 10:25, Zach Bloomquist ***@***.***> wrote:  Do you think this is a port collision issue, or what? I think that this might not be the best idea because of how new browser processes interact with existing browser processes. In the case of #5613, relaunching the browser would open up a new window in the existing browser session each time the browser is relaunched, which would be pretty undesirable behavior imo. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[flotwig]

That was my first thought, but then I remembered that (for Chromium, at least) it will only use the launched process to connect to the existing browser process and launch a window there, then exit. So closing the child process won't close the window it created in an existing session.

[bahmutov]

Hmm so maybe it is a problem with previous chrome instance NOT exiting correctly, not with the new instant spawning

…

Sent from my iPhone

On Mar 31, 2020, at 10:48, Zach Bloomquist ***@***.***> wrote:  That was my first thought, but then I remembered that (for Chromium, at least) it will only use the launched process to connect to the existing browser process and launch a window there, then exit. So closing the child process won't close the window it created in an existing session. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[flotwig]

In #5613's case it's having two copies of Cypress open that causes it. I've also seen GPO on Windows cause --user-data-dir to be ignored, so it launches in the users existing non-Cypress browser session.

Maybe it could make sense in CI only?

[bahmutov]

I wonder if we print list of all running processes on this error

…

Sent from my iPhone

On Mar 31, 2020, at 11:21, Zach Bloomquist ***@***.***> wrote:  In #5613's case it's having two copies of Cypress open that causes it. I've also seen GPO on Windows cause --user-data-dir to be ignored, so it launches in the users existing non-Cypress browser session. Maybe it could make sense in CI only? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[bahmutov]

Another user just commented that the first spec ran fine on CI, but the second could not connect. Points in favor of first browser not shutting down correctly, preventing connecting when we spawn the browser again.

Maybe if we cannot connect, we could use https://github.com/sindresorhus/ps-list to see if Chrome is hanging around and try to kill it. Or do it by default after shutting down the browser, instead of assuming it has exited.

[jennifer-shehane]

Yes, most recently I have seen this occur during cypress run in people's logs when there are multiple spec files in a run - never really happens on first open.

[cypress-app-bot]

This issue has not had any activity in 180 days. Cypress evolves quickly and the reported behavior should be tested on the latest version of Cypress to verify the behavior is still occurring. It will be closed in 14 days if no updates are provided.

[cypress-app-bot]

This issue has been closed due to inactivity.