Timed out waiting for the browser to connect - Cannot read properties of null (reading 'getWebSocketDebuggerUrl')

[danielbayerlein]

Current behavior

Since updating to Node v20.9.0 and Cypress v13.6.0, my tests are failing with a timeout error. The problem only occurs in the CI (gitlab-runner 16.5.0).

Running: login/login.cy.ts (1 of 9)
Timed out waiting for the browser to connect. Retrying...
Cannot read properties of null (reading 'getWebSocketDebuggerUrl')
TypeError: Cannot read properties of null (reading 'getWebSocketDebuggerUrl')
at Object.open (:4454:111131)
at async Object.open (:4460:27335)
at async v.relaunchBrowser (:4526:36933)

Desired behavior

No response

Test code to reproduce

Cypress Version

13.6.0

Node version

20.9.0

Operating System

public.ecr.aws/cypress-io/cypress/base:20.9.0

Debug Logs

No response

Other

Browser: Electron 114 (headless)

[danielbayerlein]

Similar issue with Chrome instead of Headless: #27915

[jeremyriverain]

I encounter the same problem in gitlab CI, running Cypress 13.4.0 with Node 18 and Chrome 110

[jennifer-shehane]

@jeremyriverain Oh, I was going to suggest downgrading to 13.4.0 to see if this issue is resolved. 😕

@danielbayerlein Can you try downgrading to 13.4.0 to see if your issue specifically is resolved?

Could you run Cypress in debug mode mode and print the entire set of logs here?

[Colorfulstan]

I tried to downgrade to 13.3 and still got a timeout waiting for the browser (without the Websocket part though)

downgrading to v12 seems to work now.
I might be able to provide you debug logs in a more private channel if that's possible

It doesn't happen reliably every time, but it feels like 50% of our CI runs are effected since upgrading Cypress from 9 to 13 in a section of our repo

EDIT: downgrading to 12 encountered a similar issue.

Tried to upgrade again setting this env variable, without additional success:
#27623

[danielbayerlein]

Can you try downgrading to 13.4.0 to see if your issue specifically is resolved?

@jennifer-shehane Same issue with version 13.4.0

[daangeerdink]

We've encountered the same issue and found out that version 13.2 works, but 13.4 or 13.6 don't.

[qooban]

Experiencing the same issue in our CI with the following setup:

Cypress:        13.6.0
Browser:        Electron 114 (headless)
Node Version:   v20.9.0 (/usr/local/bin/node)

[Rukato]

I'm on the same boat, any updates on possible fixes?

  (Run Starting)

  Cypress:        13.6.1                                                                         
  Browser:        Electron 114 (headless)                                                        
  Node Version:   v20.9.0 (/usr/local/bin/node)                                                  
  Experiments:    experimentalRunAllSpecs=true                                                   

[cg-roling]

We've worked around it by setting the CYPRESS_INTERNAL_BROWSER_CONNECT_TIMEOUT environment variable to 300000, a tip we picked up from #26936.

Oddly enough, I believe we were seeing this behavior previously with Chrome, and it only recently started happening with Electron. I think Electron used to wait to start looking for the browser until after compilation had finished.

[ayang3]

Hi @cg-roling, how did you set the CYPRESS_INTERNAL_BROWSER_CONNECT_TIMEOU variable as setting it in Cypress.config.js or to the cypress run API does not seem to be working?

[vformi]

Hello, I am experiencing the same issue.

Cypress:        13.6.1                                                                         │
  │ Browser:        Electron 114 (headless)                                                        │
  │ Node Version:   v20.9.0 (/usr/local/bin/node)    

Cannot read properties of null (reading 'getWebSocketDebuggerUrl')
TypeError: Cannot read properties of null (reading 'getWebSocketDebuggerUrl')
    at Object.open (<embedded>:4454:111164)
    at async Object.open (<embedded>:4460:27335)
    at async v.relaunchBrowser (<embedded>:4526:36933)

I dont know how to properly set the CYPRESS_INTERNAL_BROWSER_CONNECT_TIMEOUT. How can i do it ?

I have tried to do something like this but the problem still persist...

combined_frontend_tests:
  image: cypress/base:latest
  stage: test
  variables:
    CYPRESS_INTERNAL_BROWSER_CONNECT_TIMEOUT: 300000 # Timeout in milliseconds
    # Set other environment variables that Cypress uses for debugging as needed
  before_script: []

Has anyone found another solution ?

[Azuka]

If it helps, I have cypress locked to 13.2.0 and that appears to work.

Every time I try to upgrade, it works locally, but fails in CI (github-actions).

[UlanaXY]

Same issue, cypress 13.6.3 was run in official docker image cypress/base:20.10.0. Full debug log:
https://gist.github.com/UlanaXY/e0ef5fb6b8b4ae0eaae92a419b8cdef6

[crippy]

I have also just downgraded our project cypress version to 13.2.0 and appears to work ok on bitbucket also. We were running 13.6.3 and had the same issue of it timing out every time.

webpack 5.88.2 compiled successfully in 85275 ms waiting for the browser connection so tests start to run.

Will report of any issues moving forward with 13.2.0 but so far ok with image: cypress/base:16.14.0.

[cerealcable]

We have this problem as well. Going from 13.6.4 to 13.2.0 works for us as well, but certainly just a workaround until the problem is fixed.

[sergiubologa]

Hi @cg-roling, how did you set the CYPRESS_INTERNAL_BROWSER_CONNECT_TIMEOU variable as setting it in Cypress.config.js or to the cypress run API does not seem to be working?

When I look at the code where that env variable is used seems like it's expected to exist in the OS's env variables list.

So what you need to do is set an OS env variable before running the tests. Something like this, in your package.json file should work:

"component-tests": "cross-env CYPRESS_INTERNAL_BROWSER_CONNECT_TIMEOUT=300000 cypress run --component ..."

[cerealcable]

We were able to fix our issue by adding CYPRESS_INTERNAL_BROWSER_CONNECT_TIMEOUT=300000. Thanks for the helpful tips here. We ended up being able to stay current with the latest cypress releases.

[sergiubologa]

We were able to fix our issue by adding CYPRESS_INTERNAL_BROWSER_CONNECT_TIMEOUT=300000. Thanks for the helpful tips here. We ended up being able to stay current with the latest cypress releases.

We're also using the CYPRESS_INTERNAL_BROWSER_CONNECT_TIMEOUT=300000 flag and it works most of the time but still reproduces from time to time. This doesn't fix the issue entirely.

[NathanKleekamp]

Any chance this issue can get some love? We encounter this error multiple times a day with Gitlab CI v16.10.2-ee and Cypress v13.6.3. I cannot downgrade to a working version of Cypress (v13.2.0) because we need TS features from the most recent version.

It's like a 50/50 shot if this appears on any given CI run, and I'm not being hyperbolic

[Squixx]

Still happening on 13.8.1

[jennifer-shehane]

• Is this only ever happening in Electron? Does this also happen when running --browser=chrome?
• Can anyone narrow down which version introduces the issue? Is it 13.3.0? 13.3.1? 13.3.2? 13.3.3? 13.4.0?

I looked through all of the commits between 13.2.0 and 13.4.0 and is is really not obvious what the problem could be. I didn't immediately see where any code would have been touched affecting this area.

Ideally a reproducible example will allow us to investigate.

[jennifer-shehane]

Actually I may have tracked this down to this PR: #28180 which means it would have been introduced in 13.5.0. That doesn't exactly account for people saying that updating to 13.4.0 doesn't resolve the issue though.

[jamiehicks154]

I have the same issue on a much older version of Cypress which I was looking to upgrade before I ran into the issue, just adding a comment in case it's useful as my version "9.7.0" seems to be getting the same issues as others on much newer versions.

[AtofStryker]

I'm having a lot of issues reproducing this in the wild, but since @UlanaXY sent over some debug logs, I was able to go through those and get a rough idea as to what is happening. From what I can see it looks related to the work done in #28180 (and maybe colliding with #25898?).

Going through the logs, I can see that the browser has two tabs set up at time of log availability (i.e. two targets). This is not normal from what I can see on regular runs. There should only be one target tab, plus the debugger port. The two targets in this case are as follows:

• 5CF5B7DE5262708EB8D79991A162D0D4
• 6E738EFB1B226956BD5888689BB5D616

We can also see later on in the logs that after:browser:launch is NOT set up (at least according to the logs).

We can see a new process is being opened, but there is likely a launchAttempt mismatch, so the process is killed. When this happens:

• The CRI client that is closed belongs to target 5CF5B7DE5262708EB8D79991A162D0D4
• But the target that is destroyed is 6E738EFB1B226956BD5888689BB5D616

It looks like 5CF5B7DE5262708EB8D79991A162D0D4 is the active target but its CRI client is now closed, as we can see that later on we get the log that the CRI client is disconnected, but will not reconnect to it because its closed, meaning when we try to access the getWebSocketDebuggerUrl on target 5CF5B7DE5262708EB8D79991A162D0D4, it is null and throws the error.

Since this is in the general CRI client and likely a bug with how we are handling multiple browser/tab instances / mismatch on the active instance, it explains why its very intermittent (since it requires multiple tabs to be active) and can happen in any supported browser. (why we see it in electron and chromium).

Hypothetically a user could create a new tab with the puppeteer plugin which could have some side effects. @UlanaXY, @danielbayerlein or anyone else confirm if you are using this feature or not?

My best guess is that the correct behavior would be only one target from the start, and if two are required for other reasons (possibly the puppeteer plugin or a user clicked on an external link that opened another tab?), the CRI client that needs to be disconnected also needs to be the target that is destroyed.

Is anyone else able to send debugger logs to verify similar behavior? Since I can't reproduce the issue, @UlanaXY 's logs are the best I have to go off of for now. Even better if someone has a reproducible example!

[sergiubologa]

I'm having a lot of issues reproducing this in the wild, but since @UlanaXY sent over some debug logs, I was able to go through those and get a rough idea as to what is happening. From what I can see it looks related to the work done in #28180 (and maybe colliding with #25898?).
...

@AtofStryker How come setting the env variable CYPRESS_INTERNAL_BROWSER_CONNECT_TIMEOUT=300000 reduces its reproduction rate significantly.

[AtofStryker]

I've been working on @ryanthemanuel on the issue and it looks like we can mock the reproduction of the issue 🎉 (specifically to electron) to force the first instance of the browser to time out rapidly and create an orphaned browser process 4d80ef8.

A possible solution might be to preserve the CRI client in the case of electron since the browser instance is really shared across windows, so the CRI client should be the same. Still confirming and testing...

[AtofStryker]

I'm having a lot of issues reproducing this in the wild, but since @UlanaXY sent over some debug logs, I was able to go through those and get a rough idea as to what is happening. From what I can see it looks related to the work done in #28180 (and maybe colliding with #25898?).
...

@AtofStryker How come setting the env variable CYPRESS_INTERNAL_BROWSER_CONNECT_TIMEOUT=300000 reduces its reproduction rate significantly.

My best guess is that CYPRESS_INTERNAL_BROWSER_CONNECT_TIMEOUT is giving significant time for the browser process to get going, so the likelihood of orphaned processes goes down significantly. For our mock reproduction, we essentially remove this option to make the timeout super short on the first launch to near guarantee an orphaned process 4d80ef8.

[UlanaXY]

Hypothetically a user could create a new tab with the puppeteer plugin which could have some side effects. @UlanaXY, @danielbayerlein or anyone else confirm if you are using this feature or not?

For me, it was a standard run. I didn't try to create multiple tabs, or anything similar. My test includes cy.origin(), but I don't know if it's relevant in this case.