cypress: Cypress 7. Component tests. File limit reached error is shown on CI

Here are my findings. I used the react-multi-crop from @berviantoleo (see this comment) to test and debug, since it consistently exhibits the file limit error on cypress@7.7.0, but works fine on cypress@7.6.0.

Isolating the Problem

To isolate the problem, I ran the same pipeline on both GH Actions and CircleCI - this problem only manifests on GH Actions, which in my experience, have less powerful machines than CircleCI. Is everyone experiencing this problem on GH Actions? Are you able to reproduce locally? If you are experiencing it locally, are you running in docker? I’m trying to narrow the problem down, I suspect it’s a docker (or a docker-in-github-actions) problem. @pashidlos @ckxddd0324 @Asharma86 @andrico1234.

Fixing the Problem (7.6.0 -> 7.7.0)

I diff cypress@7.6.0 and cypress@7.7.0 and found that this line is causing the problem, at least in the react-multi-crop example. Between cypress@7.6.0 and cypress@7.7.0 , I removed a check which causes an additional spec watcher to start in E2E mode. 🤦 This watcher should not start in cypress run, only cypress open, so I made a PR fixing that.

Seems the file limit error is a problem for @pashidlos in cypress@7.4.0, so the PR I made probably won’t solve that problem, but it’s a good start and should help some people out who encountered problems when upgrading from cypress@7.6.0.

Other Solutions (Chokidar pollling)

For other readers, until we find a more sustainable solution (such as @pashidlos, who has this problem pre cypress@7.6.0) I found around work-around might be useful to you. Here’s some more information i found regarding GH Actions, docker and watching files, which points out the underlying problem is “you are watching too many files”. To watch less files with chokidar (which is what Cypress, and basically every other Node.js based tool uses) we can use the usePolling option. It fixes the problem in the react-multi-crop example. You could give that a try and see if it works - it’s working for react-multi-crop:

• react-multi-crop failing with Cypress 7.7.0, CHOKIDAR_USEPOLLING: 0 (default is 0) https://github.com/lmiller1990/react-multi-crop/runs/3168834559?check_suite_focus=true#step:7:56

• react-multi-crop passing with Cypress 7.7.0, CHOKIDAR_USEPOLLING: 1 https://github.com/lmiller1990/react-multi-crop/runs/3168920083?check_suite_focus=true#step:7:113

Here’s how you can use the CHOKIDAR_USEPOLLING: 1 option: https://github.com/lmiller1990/react-multi-crop/commit/9ad840a175ec58c3c127f552b52a9a94d051d64b

Seems like this is fixed.

If it comes up again or in another context, please make a new issue! Thanks team.

@pashidlos, @jennifer-shehane , this is happening for my team as well and I commented on a closed issue so this comment is to connect both issues.

https://github.com/cypress-io/cypress/issues/6960#issuecomment-884197117

cc: @adi518, @sterling, @ckxddd0324, @jakub-bao

Please wait for the next release and see if that fixes your problem. In the meantime, you could try the CHOKIDAR work around. I’d say using the dashboard is not relevant here, I think the problem is related to the CI provider.

@lmiller1990 thanks for extensive description!

first time I discovered this issue with 7.4.0 running inside docker on internal company CI (TeamCity) and we were managed to solve that (I guess as described here) so unfortunately I could not reproduce it anymore with 7.4.0 those were the logs

[10:15:06]Status: Downloaded newer image for cypress/included:7.4.0
[10:15:06]docker.io/cypress/included:7.4.0
[10:15:12]ℹ ｢wds｣: Project is running at http://localhost:34898/webpack-dev-server/
[10:15:12]ℹ ｢wds｣: webpack output is served from /__cypress/src
[10:15:12]ℹ ｢wds｣: Content not from webpack is served from /opt/buildAgent/work/4f81f6d47f6aa03/client
[10:15:13]Error: ENOSPC: System limit for number of file watchers reached, watch 'cypress/component/CreatePaymentPage.cy-spec.tsx'
[10:15:13]    at FSWatcher.<computed> (internal/fs/watchers.js:218:26)
[10:15:13]    at Object.watch (fs.js:1525:34)
[10:15:13]    at createFsWatchInstance (/root/.cache/Cypress/7.4.0/Cypress/resources/app/packages/server-ct/node_modules/chokidar/lib/nodefs-handler.js:116:15)
[10:15:13]    at setFsWatchListener (/root/.cache/Cypress/7.4.0/Cypress/resources/app/packages/server-ct/node_modules/chokidar/lib/nodefs-handler.js:163:15)
[10:15:13]    at NodeFsHandler._watchWithNodeFs (/root/.cache/Cypress/7.4.0/Cypress/resources/app/packages/server-ct/node_modules/chokidar/lib/nodefs-handler.js:325:14)
[10:15:13]    at NodeFsHandler._handleFile (/root/.cache/Cypress/7.4.0/Cypress/resources/app/packages/server-ct/node_modules/chokidar/lib/nodefs-handler.js:355:23)
[10:15:13]    at NodeFsHandler._addToNodeFs (/root/.cache/Cypress/7.4.0/Cypress/resources/app/packages/server-ct/node_modules/chokidar/lib/nodefs-handler.js:617:21)
[10:15:13] {
[10:15:13]  errno: -28,
[10:15:13]  syscall: 'watch',
[10:15:13]  code: 'ENOSPC',
[10:15:13]  path: 'cypress/component/CreatePaymentPage.cy-spec.tsx',
[10:15:13]  filename: 'cypress/component/CreatePaymentPage.cy-spec.tsx'
[10:15:13]}

the second time it was on GH Actions with 7.6.0 and it’s fixed with your workaround

I ended up downgrading and running it with the command above and it worked. Cypress clearly has a bug somewhere. I’d close this issue to avoid duplication though.

@pashidlos, @jennifer-shehane , this is happening for my team as well and I commented on a closed issue so this comment is to connect both issues.

#6960 (comment)

cc: @adi518, @sterling, @ckxddd0324, @jakub-bao

Thanks for tagging me this! Hope Cypress can solve this with a quick hot-fix

I ended up downgrading and running it with the command above and it worked. Cypress clearly has a bug somewhere. I’d close this issue to avoid duplication though.

Thanks @adi518 for sharing the workaround - it worked for me. Hope Cypress can update us here once it is fixed.

cc: @jennifer-shehane

I’m having a similar issue,

Even with "watchForFileChanges": false, set in the cypress.json, running "yarn cypress run --record --ci-build-id #{Build.BuildNumber}# --group '#{Build.DefinitionName}#'" in our CI pipeline throws the same warnings and errors that @pashidlos shared.