Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
danielbayerlein opened this issue Nov 24, 2023 · 28 comments · Fixed by #29515
Assignees

Comments

@danielbayerlein
Copy link

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
Copy link
Author

Similar issue with Chrome instead of Headless: #27915

@jeremyriverain
Copy link

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

@jennifer-shehane
Copy link
Member

jennifer-shehane commented Nov 28, 2023

@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?

@jennifer-shehane jennifer-shehane added the stage: needs information Not enough info to reproduce the issue label Nov 28, 2023
@Colorfulstan
Copy link

Colorfulstan commented Nov 29, 2023

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
Copy link
Author

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
Copy link

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

@qooban
Copy link

qooban commented Dec 8, 2023

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
Copy link

Rukato commented Dec 8, 2023

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
Copy link

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
Copy link

ayang3 commented Dec 15, 2023

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
Copy link

vformi commented Dec 18, 2023

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
Copy link

Azuka commented Dec 28, 2023

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
Copy link

UlanaXY commented Jan 22, 2024

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
Copy link

crippy commented Feb 12, 2024

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
Copy link

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
Copy link

sergiubologa commented Feb 19, 2024

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
Copy link

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
Copy link

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
Copy link

NathanKleekamp commented Apr 17, 2024

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
Copy link

Squixx commented Apr 24, 2024

Still happening on 13.8.1

@jennifer-shehane
Copy link
Member

  • 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
Copy link
Member

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.

@jennifer-shehane jennifer-shehane changed the title Timed out waiting for the browser to connect Timed out waiting for the browser to connect - Cannot read properties of null (reading 'getWebSocketDebuggerUrl') Apr 24, 2024
@jennifer-shehane jennifer-shehane added stage: needs investigating Someone from Cypress needs to look at this and removed stage: needs information Not enough info to reproduce the issue labels Apr 24, 2024
@jamiehicks154
Copy link

jamiehicks154 commented May 1, 2024

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.

timeout_cypress

@jennifer-shehane jennifer-shehane removed the stage: needs investigating Someone from Cypress needs to look at this label May 10, 2024
@jennifer-shehane jennifer-shehane added the stage: investigating Someone from Cypress is looking into this label May 10, 2024
@AtofStryker
Copy link
Contributor

AtofStryker commented May 13, 2024

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

Screenshot 2024-05-13 at 3 07 05 PM
Screenshot 2024-05-13 at 4 26 39 PM

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
Copy link

sergiubologa commented May 14, 2024

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link

UlanaXY commented May 14, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.