TypeError: Cannot destructure property 'data' of 'undefined' as it is undefined. at <embedded>:4649:286986

aleksandrlat commented 1 year ago

Current behavior

I have this error in test

1) Dashboard
       should render:
     TypeError: Cannot destructure property 'data' of 'undefined' as it is undefined.
      at <embedded>:4649:286986

This path at <embedded>:4649:286986 does not make sense

Desired behavior

Cypress should report correct error path

Test code to reproduce

I cannot consistently reproduce it. It happens randomly

Cypress Version

12.8.1

Node version

18.15.0

Operating System

Linux

Debug Logs

No response

Other

No response

nagash77 commented 1 year ago

Hi @aleksandrlat , I'm sorry to hear you are having issues using Cypress. Unfortunately with as little detail as you have provided we will not be able to investigate this problem. I am going to close this issue. If you are able to provide a reproducible example please comment back here and we can reopen to investigate.

wojtek1150 commented 1 year ago

Same here. Starts failing after update to v12. Only on component testing

rasiaq commented 1 year ago

Same here. Starts failing after update to v12. Only on component testing

it worth mentioning that "template" is just name of a test such as:

test("template", () =>

I can also confirm that it happens randomly, after updating to v12. There are no "before each" hooks configured, the only thing that happens before this test is component mounting

  const config: MountConfig<HeaderComponent> = {
    imports: [RouterTestingModule, BrowserAnimationsModule],
    providers: [
      provideMockStore({
        selectors: [...],
      }),
    ],
  };

  test('template', () => {
    cy.mount(HeaderComponent, config);
    cy.get('.page-header .community-name').should('have.text', 'XXX');
    cy.get('.page-header .page-title').should('contain.text', 'YYY');
    cy.get('.page-header img').should('have.attr', 'src', 'https://picsum.photos/id/237/200/300');
  });

aleksandrlat commented 1 year ago

Yeah I had the same "before each" hook for "should render" and I don't have "before each" hook in my test But we use @cypress/code-coverage and it adds before each hook automatically. I removed this plugin from code but error still happens. It is reported without "before each" hook now

1) Dashboard
       should render:
     TypeError: Cannot destructure property 'data' of 'undefined' as it is undefined.
      at <embedded>:4649:286986

lmiller1990 commented 1 year ago

Are you both using Angular?

Can someone put together a minimal reproduction? I have never seen this -- we've got dozens of projects running on CI with every commit. I don't doubt you've encountered a bug, but I haven't got any way to reproduce this. I had a look over our code base but I'm not sure where the destructure is happening 🤔

If you can share a repository I can run (even if it's randomly occurring) I can run it over and over until I encounter this.

rasiaq commented 1 year ago

Yes, @wojtek1150 and I are using Angular. \ Unfortunately, I cannot share a repository straightaway because it is a private project – I would need some time to prepare public repo with minimal reproduction. For know I can provide some more details to help you investigate it. \ This is basically the whole component + test:

@Component({
  standalone: true,
  selector: 'header',
  template: ` <div class="page-header">
    <img *ngIf="communityLogoUrl$ | async as logoUrl" [src]="logoUrl" alt="community logo" />
    <span class="community-name">{{ communityName$ | async }}</span>
    <span *ngIf="title$ | async as title" class="page-title">&nbsp;{{ title }}</span>
  </div>`,
  styleUrls: ['./header.component.scss'],
  changeDetection: ChangeDetectionStrategy.OnPush,
  imports: [AsyncPipe, NgIf],
})
export class HeaderComponent {
  readonly title$ = this.store.select<string>(title);
  readonly communityName$ = this.store.select<string>(communityName);
  readonly communityLogoUrl$ = this.store.select<string>(communityLogoUrl);

  constructor(private store: Store<AppState>) {}
}

describe(HeaderComponent.name, () => {
  const config: MountConfig<HeaderComponent> = {
    imports: [RouterTestingModule, NzIconTestModule, BrowserAnimationsModule],
    providers: [
      provideMockStore({
        selectors: [
          { selector: communityName, value: 'XXX' },
          { selector: title, value: 'My awesome title' },
          { selector: communityLogoUrl, value: 'https://picsum.photos/id/237/200/300' },
        ],
      }),
    ],
  };

  test('template', () => {
    cy.mount(HeaderComponent, config);
    cy.get('.page-header .community-name').should('have.text', 'XXX');
    cy.get('.page-header .page-title').should('contain.text', 'My awesome title');
    cy.get('.page-header img').should('have.attr', 'src', 'https://picsum.photos/id/237/200/300');
  });
});

We are using nx and code is run via @nrwl/cypress. Current versions are:

"@nrwl/cypress": "15.8.7",
"cypress": "12.8.1",
"cypress-multi-reporters": "1.6.3",

and here is the command that is being used to run component tests:

    "component-test": {
      "executor": "@nrwl/cypress:cypress",
      "options": {
        "cypressConfig": "apps/my-app/cypress.config.ts",
        "testingType": "component",
        "skipServe": true,
        "devServerTarget": "my-app:build"
      },
      "configurations": {
        "open": {
          "watch": true
        }
      }
    }

cypress.config.ts:

export default defineConfig({
  component: {
    ...nxComponentTestingPreset(__filename),
    video: false,
    viewportHeight: 768,
    viewportWidth: 1366,
    defaultCommandTimeout: 10000,
    reporter: '../../node_modules/cypress-multi-reporters',
    reporterOptions: {
      configFile: 'reporter-config.json',
    },
  },
});

aleksandrlat commented 1 year ago

@lmiller1990 I use react components. I cannot consistently reproduce it. I cannot share my code and it maybe not easy to reproduce it. How can we see code on these lines at <embedded>:4649:286986? Can we enable something to have better understanding what these lines are?

lmiller1990 commented 1 year ago

@rasiaq your code looks fine - no obvious problem 🤔

@aleksandrlat I think the issue is our use of something called "v8 snapshots". A good chunk of our code is bundled into a binary blob loaded straight into memory, which massively improves startup performance. Unfortunately, debugging is harder. There are two options you can try:

run with DEBUG=cypress:* npx cypress .... You should get a lot of additional logging in your terminal. You could share that here - it might help give us some clues.
run the development build of Cypress. You could clone this repo and point it at your project. Basically:

git clone --depth=1 https://github.com/cypress-io/cypress.git
yarn install
wait quite a while
yarn cypress:open
find your project, launch it, see if you can reproduce
hopefully see a more useful error.

ValentinSchwarzXavo commented 1 year ago

Since our cypress v12 update we're experiencing the same exception. I can share some additional stuff:

the issue itself is not reproducible, it's flaky and sometimes works, sometimes not
in our case it only occurs in the CI environment (I don't experience it on windows, a colleague once got the error on linux)
we use either npx nx affected --target=component-test or npx nx run-many --target=component-test --all to run the tests
if it fails it will only fail for the first test in a run

vapkse commented 1 year ago

Hello

Same problem for me on Jenkins. In attachment the DEBUG log.

https://raw.githubusercontent.com/vapkse/logs/main/debug-cypress-component-issue.log

node --version v18.13.0
yarn --version 1.22.19

lmiller1990 commented 1 year ago

@ValentinSchwarzXavo

Since our cypress v12 update we're experiencing the same exception

What was your previous version and what did you update to (exact versions). This would be useful.

@vapkse I see the same error in your logs, but the run continues.

Shot in the dark, but I see one common dependency here: webpack (I think) and component testing. @aleksandrlat are you also using webpack? The dev-server hasn't changed in good while, but I wonder if it's related. I assume no-one is seeing this with E2E testing (or if you are using Vite for your dev server, are you seeing it there)?

Is anyone able to provide a publicly available minimal reproduction we can run? This would help greatly.

ValentinSchwarzXavo commented 1 year ago

@lmiller1990 we upgraded from 11.2.0 to 12.2.0.

vapkse commented 1 year ago

@lmiller1990 Yes, we have this problem with component, never with e2e. We are using Angular 14.3.0 and angular uses webpack 5.76. The tests continue, but the result of the first one is a fail. If we disable the first one, the problem will be the same with the next first one., so this is not linked to the test.

I think that will be hard to reproduce, because we have two projects using the same version of the dependencies, has some test in a common repository (executed on the both projects). One is crashing 50% of the time, and the second one, never crash. The big difference between the two projects, is that the problematic one is more big and take more time to compile and load.

Note also that happens only on jenkins (linux), and never in local (windows).

Following the list of our dependencies.

"dependencies": {
    "@angular/animations": "14.3.0",
    "@angular/cdk": "14.2.7",
    "@angular/common": "14.3.0",
    "@angular/core": "14.3.0",
    "@angular/forms": "14.3.0",
    "@angular/material": "14.2.7",
    "@angular/material-date-fns-adapter": "14.2.7",
    "@angular/platform-browser": "14.3.0",
    "@angular/platform-browser-dynamic": "14.3.0",
    "@angular/router": "14.3.0",
    "@deja-js/component": "~14.2.0",
    "@fontsource/material-icons": "~4.5.4",
    "@fontsource/roboto": "~4.5.8",
    "@fortawesome/fontawesome-svg-core": "~6.4.0",
    "@fortawesome/free-regular-svg-icons": "~6.4.0",
    "@fortawesome/free-solid-svg-icons": "~6.4.0",
    "core-js": "~3.29.1",
    "date-fns": "2.29.3",
    "dejajs-dpi": "~14.20.0",
    "json-object-mapper": "~1.7.1",
    "lean-he": "~2.1.2",
    "lodash-es": "~4.17.21",
    "monaco-editor": "~0.36.1",
    "ng-event-source": "~1.0.14",
    "rxjs": "~7.8.0",
    "tslib": "~2.5.0",
    "zone.js": "~0.13.0"
},
"devDependencies": {
    "@angular-builders/custom-webpack": "~14.1.0",
    "@angular-devkit/architect": "~0.1402.10",
    "@angular-devkit/build-angular": "14.2.11",
    "@angular/cli": "14.2.11",
    "@angular/compiler": "14.3.0",
    "@angular/compiler-cli": "14.3.0",
    "@angular/language-service": "14.3.0",
    "@commitlint/cli": "~17.5.1",
    "@commitlint/config-conventional": "~17.4.4",
    "@hug/eslint-config": "~10.0.1",
    "@rxweb/types": "~1.0.8",
    "@sentry/browser": "7.45.0",
    "@types/ckeditor4": "4.16.5",
    "@types/jasmine": "~4.3.1",
    "@types/jasminewd2": "2.0.10",
    "@types/lodash-es": "~4.17.7",
    "@types/node": "~18.15.11",
    "ckeditor4": "4.21.0",
    "cypress": "12.9.0",
    "cypress-fail-fast": "7.0.0",
    "eslint": "~8.37.0",
    "eslint-plugin-deprecation": "~1.3.3",
    "husky": "~8.0.3",
    "jasmine-core": "~4.5.0",
    "jasmine-spec-reporter": "~7.0.0",
    "karma": "~6.4.1",
    "karma-chrome-launcher": "~3.1.1",
    "karma-coverage-istanbul-reporter": "~3.0.3",
    "karma-jasmine": "~5.1.0",
    "karma-jasmine-html-reporter": "~2.0.0",
    "sonarqube-scanner": "2.9.1",
    "ts-node": "~10.9.1",
    "typescript": "~4.8.4",
    "typescript-strict-plugin": "~2.1.0",
    "webpack-bundle-analyzer": "~4.8.0",
    "webpack-retry-chunk-load-plugin": "~3.1.1",
    "x2js": "~3.4.4"
},

aleksandrlat commented 1 year ago

@aleksandrlat are you also using webpack?

@lmiller1990 yes we also use webpack

rikkert09 commented 1 year ago

Hi,

We are also experiencing this issue. We're using Angular 14.3.0 and Cypress 2.7.0 and node 16.19.1. The issue only occurs on Jenkins Linux, while we couldn't reproduce it on a Windows machine locally. It only happens with component tests and on the first run. The problem started after upgrading from angular 13 to angular 14

This issue is causing a lot of problems for us, as a large number of our builds are failing because of it. We would really appreciate any help in resolving this issue as soon as possible.

Here are our dependencies:

 "dependencies": {
    "@angular/animations": "^14.3.0",
    "@angular/common": "^14.3.0",
    "@angular/compiler": "^14.3.0",
    "@angular/core": "^14.3.0",
    "@angular/forms": "^14.3.0",
    "@angular/localize": "^14.3.0",
    "@angular/platform-browser": "^14.3.0",
    "@angular/platform-browser-dynamic": "^14.3.0",
    "@angular/router": "^14.3.0",
    "@fortawesome/fontawesome-free": "^6.3.0",
    "@myndmanagement/text-mask": "^13.1.3",
    "@ng-bootstrap/ng-bootstrap": "^13.1.1",
    "@popperjs/core": "^2.11.6",
    "@syncfusion/ej2-angular-base": "20.3.47",
    "@syncfusion/ej2-angular-grids": "20.3.47",
    "@syncfusion/ej2-angular-inputs": "20.3.47",
    "@syncfusion/ej2-angular-navigations": "20.3.47",
    "@syncfusion/ej2-angular-popups": "20.3.47",
    "@syncfusion/ej2-data": "20.3.47",
    "@syncfusion/ej2-grids": "20.3.47",
    "bootstrap": "^5.2.1",
    "chromedriver": "^94.0.0",
    "fast-deep-equal": "^3.1.3",
    "ibantools": "^4.1.5",
    "moment": "^2.29.1",
    "ngx-mask": "^10.0.1",
    "rxjs": "^7.8.0",
    "tslib": "^2.4.0",
    "zone.js": "~0.11.4"
  },
  "devDependencies": {
    "@angular-devkit/build-angular": "^14.2.11",
    "@angular/cli": "^14.2.11",
    "@angular/compiler-cli": "^14.3.0",
    "@cypress/schematic": "^2.4.0",
    "@types/jest": "^28.1.3",
    "@types/node": "^17.0.35",
    "codelyzer": "^6.0.0",
    "cypress": "12.7.0",
    "cypress-multi-reporters": "^1.6.2",
    "jest": "^28.1.3",
    "jest-environment-jsdom": "^28.1.3",
    "jest-preset-angular": "^12.1.0",
    "json-server": "^0.16.3",
    "mocha": "^10.0.0",
    "mocha-junit-reporter": "^2.0.2",
    "mochawesome": "^7.1.0",
    "mochawesome-merge": "^4.2.1",
    "ng-swagger-gen": "^2.3.1",
    "npm-run-all": "^4.1.5",
    "sass": "^1.52.3",
    "source-map-explorer": "^2.5.3",
    "ts-node": "^10.9.1",
    "tslint": "^6.1.0",
    "typescript": "^4.8.2",
    "wait-on": "^6.0.0",
    "zip-folder": "1.0.0"
  },

samtjo commented 1 year ago

We are also seeing this issue with component testing, and again only when running this in CI using Github Actions. Here is the debug log for the error itself, using DEBUG=cypress:* that was mentioned above.

It seems to be related to the @cypress/code-coverage package, and resetting code coverage in particular.

Hopefully this is helpful! I can provide more info if needed.

Relevant dep versions are:

"@cypress/code-coverage": "^3.10.0",
"@cypress/webpack-dev-server": "^3.4.0",
"@nrwl/cypress": "15.8.6",
"@testing-library/cypress": "^9.0.0",
"cypress": "^12.8.1",
"webpack": "^5.76.2",


[31;1mcypress:server:reporter 
[0mgot mocha event 'fail' with args: [ { id: 
[32m'r2'
[39m, title: 
[32m'"before all" hook for "<removed my test name here>"'
[39m, hookName: 
[32m'before all'
[39m, hookId: 
[32m'h1'
[39m, err: { message: 
[32m"Cannot destructure property 'data' of 'undefined' as it is undefined.\n"
[39m + 
[32m'\n'
[39m + 
[32m'Because this error occurred during a `before all` hook we are skipping all of the remaining tests.\n'
[39m + 
[32m'\n'
[39m + 
[32m'Although you have test retries enabled, we do not retry tests when `before all` or `after all` hooks fail'
[39m, name: 
[32m'TypeError'
[39m, stack: 
[32m"TypeError: Cannot destructure property 'data' of 'undefined' as it is undefined.\n"
[39m + 
[32m'\n'
[39m + 
[32m'Because this error occurred during a `before all` hook we are skipping all of the remaining tests.\n'
[39m + 
[32m'\n'
[39m + 
[32m'Although you have test retries enabled, we do not retry tests when `before all` or `after all` hooks fail\n'
[39m + 
[32m'    at <embedded>:4649:286986\n'
[39m + 
[32m'    at process.processTicksAndRejections (node:internal/process/task_queues:96:5)\n'
[39m + 
[32m'    at async <embedded>:4649:330570'
[39m }, state: 
[32m'failed'
[39m, pending: 
[33mfalse
[39m, body: 
[32m'() => {\n'
[39m + 
[32m'    // we need to reset the coverage when running\n'
[39m + 
[32m'    // in the interactive mode, otherwise the counters will\n'
[39m + 
[32m'    // keep increasing every time we rerun the tests\n'
[39m + 
[32m'    const logInstance = Cypress.log({\n'
[39m + 
[32m"      name: 'Coverage',\n"
[39m + 
[32m"      message: ['Reset [@cypress/code-coverage]']\n"
[39m +
[32m'    })\n'
[39m + 
[32m'\n'
[39m + 
[32m'    cy.task(\n'
[39m + 
[32m"      'resetCoverage',\n"
[39m + 
[32m'      {\n'
[39m + 
[32m'        // @ts-ignore\n'
[39m + 
[32m"        isInteractive: Cypress.config('isInteractive')\n"
[39m + 
[32m'      },\n'
[39m + 
[32m'      { log: false }\n'
[39m + 
[32m'    ).then(() => {\n'
[39m + 
[32m'      logInstance.end()\n'
[39m + 
[32m'    })\n'
[39m + 
[32m'  }'
[39m, type: 
[32m'hook'
[39m, duration: 
[33m22
[39m, file: 
[32m'src/components/MyTestFile.cy.tsx'
[39m, originalTitle: 
[32m'"before all" hook'
[39m, invocationDetails: { function: 
[32m'Object.getInvocationDetails'
[39m, fileUrl: 
[32m'http://localhost:8080/__cypress/runner/cypress_runner.js'
[39m, originalFile: 
[32m'http://localhost:8080/__cypress/runner/cypress_runner.js'
[39m, line: 
[33m159265
[39m, column: 
[33m17
[39m, whitespace: 
[32m'    '
[39m, stack: 
[32m'Error\n'
[39m + 
[32m'    at Object.getInvocationDetails (http://localhost:8080/__cypress/runner/cypress_runner.js:159265:17)\n'
[39m + 
[32m'    at Suite._createHook (http://localhost:8080/__cypress/runner/cypress_runner.js:156510:98)\n'
[39m + 
[32m'    at ../driver/node_modules/mocha/lib/suite.js.Suite.beforeAll (http://localhost:8080/__cypress/runner/cypress_runner.js:106464:19)\n'
[39m + 
[32m'    at Suite.<computed> [as beforeAll] (http://localhost:8080/__cypress/runner/cypress_runner.js:156523:23)\n'
[39m + 
[32m'    at before (http://localhost:8080/__cypress/runner/cypress_runner.js:100388:17)\n'
[39m + 
[32m'    at registerHooks (http://localhost:8080/__cypress/src/vendors-node_modules_cypress_code-coverage_support_js-node_modules_testing-library_cypress_ad-9ddf25.js:207:3)\n'
[39m + 
[32m'    at ../../../node_modules/@cypress/code-coverage/support.js (http://localhost:8080/__cypress/src/vendors-node_modules_cypress_code-coverage_support_js-node_modules_testing-library_cypress_ad-9ddf25.js:402:3)\n'
[39m + 
[32m'    at __webpack_require__ (http://localhost:8080/__cypress/src/main.js:21:41)\n'
[39m + 
[32m'    at ../../../cypress-config/support/component.ts (http://localhost:8080/__cypress/src/cypress-support-file.js:72:1)\n'
[39m + 
[32m'    at __webpack_require__ (http://localhost:8080/__cypress/src/main.js:21:41)'
[39m }, currentRetry: 
[33m0
[39m, retries: 
[33m-1
[39m, _slow: 
[33m250
[39m } ] 
[31m+17ms
[0m```

aleksandrlat commented 1 year ago

I tried to remove @cypress/code-coverage but it didn't help Please see my message above https://github.com/cypress-io/cypress/issues/26187#issuecomment-1482988719

samtjo commented 1 year ago

Yeah I had the same experience with removing @cypress/code-coverage, the error then turned up in an "after all" hook instead.

lmiller1990 commented 1 year ago

It sounds like has popped up recently - a number of people are encountering it, all at the same time 🤔

Quick summary so we can start to narrow things down...

is that the problematic one is more big and take more time to compile and load
CI using Github Actions
occurs on Jenkins Linux, while we couldn't reproduce it on a Windows machine locally.
it only happens with component tests and on the first run
the problem started after upgrading from Angular 13 to Angular 14
webpack
Starts failing after update to v12
use Angular

The common thing is... webpack on CI, from the looks of things. Angular is a pretty huge bundle - I wonder if this is a race condition. That would make it more likely to occur in a big webpack project, like many Angular projects are. Sounds eerily similar to https://github.com/cypress-io/cypress/issues/25913.

We can definitely get someone to spend time on this, but without a reproduction, I feel like we are going in to this blind.

If anyone who is experiencing this on CI (sounds like this is only really a CI issue) is able to try bumping up their CI machine resources/CPU etc to see if that fixes it, that would be great -- obviously this wouldn't be the fix, but it would confirm that this is a race condition, which would at least give us somewhere to start looking.

In the meantime, I am going to try run some Angular projects I know of on a bare bones machine (512mb) and see if I can run into this.

lmiller1990 commented 1 year ago

Edit - hi all, how many of you are using parallelization? I'm battling something similar here: https://github.com/cypress-io/cypress/issues/25913#issuecomment-1498616417 which looks like it's far more likely to happen when running multiple containers in parallel. Does this sound like anyone else running into this issue? If you turn of paralellization, do you encounter the issue as frequently?

ValentinSchwarzXavo commented 1 year ago

@lmiller1990 We turned of parallelization due to the issue - but it didn't help.

lmiller1990 commented 1 year ago

@ValentinSchwarzXavo You mentioned "we upgraded from 11.2.0 to 12.2.0" - reverting fixes this issue? If this is related to a code change, that would be vastly easier to debug. 11.2 -> 12.2 has a bunch of minor in between - any chance you'd have some bandwidth to narrow it down (this is assuming that 11.2 is working fine, and 12.2 is not).

ValentinSchwarzXavo commented 1 year ago

@lmiller1990 Reverting to 11.2.0 fixed the issue - but we had another issue in 11.2.0, that's why we initially upgraded to try to get rid of the issue. But we didn't try to minor-upgrade.

samtjo commented 1 year ago

@lmiller1990 I forgot to mention, we aren't using Angular at all. We're getting this error with React component testing.

We have also recently started using 16 core custom runners for our Github Actions, but this doesn't seem to have impacted this error cropping up at all.

lmiller1990 commented 1 year ago

@ValentinSchwarzXavo Can you try and isolate the minor that broke you? That'd help a lot. What's the other issue you ran into (and was it fixed by upgrading)? @samtjo How many parallel runs are you doing? I guess it happens without parallelization too, though 🤔 ?

I'm sorry you are all running into this - thanks for the quick feedback all - I know it's frustrating. Happy to spend a good chunk of engineering time investigating and fixing this, but I think we need to narrow it down so we can start trying things. It seems like this is exclusively happening to webpack projects, which is really useful information.

niko-and commented 1 year ago

Hi. We are having a similar issue. I believe tests fail intermittently with the same error output. One thing i noticed that will always trigger this error (at least from my test runs) is if you run only ONE test in your pipeline. Example: with using it.only(). We are not using parallelization and this happens with Angular component testing in our gitlab pipeline. Our versions: Cypress: 12.9.0
Browser: Electron 106 (headless)
Node Version: v16.18.1 (/usr/local/bin/node)

samtjo commented 1 year ago

@samtjo How many parallel runs are you doing? I guess it happens without parallelization too, though 🤔 ?

@lmiller1990 We have the parallel flag set to false, so no parallel runs for us. Not using Cypress anyway, we're splitting our tests into parallel runs using a matrix in Github Actions

rikkert09 commented 1 year ago

It sounds like has popped up recently - a number of people are encountering it, all at the same time 🤔

Quick summary so we can start to narrow things down...

I saw that besides the angular update we also updated cypress in Jenkins from version 12.2.0 to 12.7.0. When I downgrade to 12.2.0 it looks like the problem is solved.

koenvangeert commented 1 year ago

Hey, I ran cypress with the dev build to get better stacktraces and received the following: I looks to be related to taking screenshots. Hope this helps.

Fyi, changing the config to screenshotOnRunFailure: false, doesn't seem to help

TypeError: Cannot destructure property 'data' of 'undefined' as it is undefined.

Because this error occurred during a `before all` hook we are skipping all of the remaining tests.

Although you have test retries enabled, we do not retry tests when `before all` or `after all` hooks fail
      at /Users/koen.vangeert/workspaces/cypress/packages/server/lib/browsers/cdp_automation.ts:342:18
      at /Users/koen.vangeert/workspaces/cypress/packages/server/lib/browsers/electron.ts:78:23
  From previous event:
      at /Users/koen.vangeert/workspaces/cypress/packages/server/lib/automation/automation.ts:55:25
      at Object.capture (/Users/koen.vangeert/workspaces/cypress/packages/server/lib/screenshots.js:402:15)
      at Object.capture (/Users/koen.vangeert/workspaces/cypress/packages/server/lib/automation/screenshot.ts:6:26)
      at /Users/koen.vangeert/workspaces/cypress/packages/server/lib/automation/automation.ts:104:34
  From previous event:
      at Automation.normalize (/Users/koen.vangeert/workspaces/cypress/packages/server/lib/automation/automation.ts:101:25)
      at /Users/koen.vangeert/workspaces/cypress/packages/server/lib/automation/automation.ts:170:19
      at processImmediate (node:internal/timers:466:22)
      at process.callbackTrampoline (node:internal/async_hooks:130:18)
  From previous event:
      at Automation.request (/Users/koen.vangeert/workspaces/cypress/packages/server/lib/automation/automation.ts:169:6)
      at automationRequest (/Users/koen.vangeert/workspaces/cypress/packages/server/lib/socket-base.ts:164:25)
      at Socket.<anonymous> (/Users/koen.vangeert/workspaces/cypress/packages/server/lib/socket-base.ts:263:16)
      at Socket.emit (node:events:527:29)
      at Socket.emitUntyped (<embedded>:838131:21)
      at <embedded>:838393:32
      at processTicksAndRejections (node:internal/process/task_queues:78:12)

samtjo commented 1 year ago

I also downgraded to Cypress version 12.2.0 earlier and was no longer getting the error.

After that I have gone back to Cypress 12.8.1 and changed the browser my tests run in from Electron to Chrome, and have not seen the error in 9 consecutive CI runs, so I'm pretty confident that has resolved it. I was getting it on at least one of my many tests in every CI run before.

ValentinSchwarzXavo commented 1 year ago

@lmiller1990 It started to be broken with the initial 12 release. The other issue we had with 11.2.0 was some spy in the component test that didn't take effect - unfortunately it's still broken with 12.2.0 for us. But that's a different story.

lmiller1990 commented 1 year ago

@koenvangeert wow thanks! That stack trace suggests

https://github.com/cypress-io/cypress/blob/89c23e08de76ff37093ac6c6958a8ffdaecc4fc0/packages/server/lib/browsers/cdp_automation.ts#L342

Is the source of the error.

@samtjo @rikkert09 Sounds like something between 12.2 and 12.7 broke. Is anyone able to isolate the minor? The diff between these two releases is pretty significant. Alternative, if you are you using our docker containers, it could be a browser version that broke something?

After that I have gone back to Cypress 12.8.1 and changed the browser my tests run in from Electron to Chrome, and have not seen the error in 9 consecutive CI runs, so I'm pretty confident that has resolved it

I didn't even think about this, but I wonder if it's Electron specific. @koenvangeert's error points to an electron issue (related to CDP, which Chrome uses too, but still). Last electron update was to v12 in Cy 10.9.

If it's not much trouble, what would really help:

Try Chrome instead of Electron. Does that fix it? Then we know where to look.
If you found an issue between Cy 12.2 nad 12.7, figure out the minor and we can do a deep dive.

koenvangeert commented 1 year ago

@koenvangeert wow thanks! That stack trace suggests

https://github.com/cypress-io/cypress/blob/89c23e08de76ff37093ac6c6958a8ffdaecc4fc0/packages/server/lib/browsers/cdp_automation.ts#L342

Is the source of the error.

@samtjo @rikkert09 Sounds like something between 12.2 and 12.7 broke. Is anyone able to isolate the minor? The diff between these two releases is pretty significant. Alternative, if you are you using our docker containers, it could be a browser version that broke something?

After that I have gone back to Cypress 12.8.1 and changed the browser my tests run in from Electron to Chrome, and have not seen the error in 9 consecutive CI runs, so I'm pretty confident that has resolved it

I didn't even think about this, but I wonder if it's Electron specific. @koenvangeert's error points to an electron issue (related to CDP, which Chrome uses too, but still). Last electron update was to v12 in Cy 10.9.

If it's not much trouble, what would really help:

Try Chrome instead of Electron. Does that fix it? Then we know where to look.

If you found an issue between Cy 12.2 nad 12.7, figure out the minor and we can do a deep dive.

@lmiller1990

Switching to chrome resolved the issue.
This will take some time. I'll let you know if I found out which version did it.

koenvangeert commented 1 year ago

It is flaky by nature so I'm not 100% sure. I tried reproducing the bug for each version 3 times. 12.2 => Ok for me 12.3 => Ok for me 12.4 => Ok for me 12.4.1 => Ok for me 12.5 => Ok for me 12.5.1 => Skipped testing this one 12.6 => Ok for me 12.7 => Starts showing the error

koenvangeert commented 1 year ago

After doing git bisect I hit the following commit to be the first place where it shows up. https://github.com/cypress-io/cypress/pull/25898

rzavala-suplari commented 1 year ago

I've updated from 12.7.0 to 12.9.0. The issue persists.

:4613:286986 at async :4613:330570]]>

mike-plummer commented 1 year ago

I've spent a bit of time looking at this and have not been able to reproduce this issue which makes it very difficult to track down exactly what is going wrong. I will make some changes to the specific line of code that's blowing up so we get a more meaningful error, but that won't address the underlying issue (simply change how it's reported in the logs). If anyone can supply a reproduction case that would be extremely helpful since this appears to be a combination of CI configuration, resourcing, and component testing project structure/size that is difficult to replicate without a starting point.

There are a few things that I can suggest pending a reproduction being provided:

This appears to be specific to Electron - using Chrome or Firefox may be a workaround depending on your use case
Some of the attached logs seem to indicate potential issues with IPv6 networking which can cause problems in Electron. You may want to validate the base OS image being used in CI to ensure it isn't unnecessarily outdated
Please check if there are any custom plugins or event handlers that may be attempting to intercept or act on browser start/stop events. These may not have been updated to account for changes to browser launching that were made in 12.7.0

tvsbrent commented 1 year ago

I'm not sure if this is a helpful report or is just adding more noise, but this issue recently cropped up for us in a few projects.

In our case, it was after a Renovate PR came through and upgraded a handful of dependencies. Based on the discussion here, we decided to downgrade the project's version of Webpack. The Renovate PR had upgraded it to 5.81.0 from 5.76.3. We reverted just that change, rolling back to 5.76.3, and the builds following that are passing. We've only tried it in one project so far, so I wouldn't call it a smoking gun or anything, but it felt worth sharing.

Another random bit that we noticed is that a new warning has started to appear in the component build logs that wasn't there previously: Timed out waiting for the browser to connect. Retrying.... This is only seen when running component tests in the project, not E2E tests.

EDIT: Forgot to share that we are using Cypress 12.8.1 in all our projects and have been since late March 2023. It was only after these upgrades were applied this past weekend that we started seeing this issue.

bradley-carestia-jbh commented 1 year ago

This issue still present in 12.11. Contributing to the race condition theory, it seems to fail more on big projects than small ones (when running many projects with Nx affected). Switching to Chrome browser does seem to fix it at least

lmiller1990 commented 1 year ago

The Renovate PR had upgraded it to 5.81.0 from 5.76.3 (webpack)

Interesting - it looks like was likely introduced in a third party library that we integrate with - we still need to fix it in some fashion here. Are you on Angular - seems so? @tvsbrent?

Angular is a bit framework with a massively complex internal webpack config - I'm guessing the complexity makes things slower which is why the race condition manifests more frequently when using Angular.

mvts commented 1 year ago

We are using React with Cypress 12.8.0 and we experience the same issue where it's failing more often than not while deploying on AWS Amplify.

peterhodges commented 1 year ago

Seeing this with NX/Angular on Github Actions.

Seems to run the tests for one lib consistently, but adding a second library fails. Parallel=false within the worker that runs the component-tests.

erinversfeldcodes commented 1 year ago

For what it's worth, we've been able to reliably reproduce this error by: 1) running tests in a docker container built from the cypress/included:12.16.0 image 2) running that container as part of a GCP build pipeline 3) defining a function, task, in cypress.config.js like this:

    setupNodeEvents(on, config) {
      on("task", {
        log(message) {
          console.log(message);
          return null;
        },
      });
    },

4) having the test print some output like this: cy.task("log", "env (_MY_VAR): " + Cypress.env("_MY_VAR"));

The test will then output something like this, causing the test to register as having failed:

      at <embedded>:5154:286986
     TypeError: Cannot destructure property 'data' of 'undefined' as it is undefined.
       env vars test succeeds:
  1) test env vars

lmiller1990 commented 1 year ago

Thanks for the tip @erinversfeldcodes - I will give this a try.

rgoyalmw commented 1 year ago

Hi,

I am also facing this issue currently and for me it was sporadic before but now in the majority of the runs, I see this error.

I am running component tests on cypress version 12.9.0

Here is what I have in my cypress.config.js file: ` setupNodeEvents(on, config) {

  on("task", {
    log(args) {
      console.log(...args);
      return null;
    }
  });

  console.log('setupNodeEvents for components')

  // https://github.com/bahmutov/cypress-code-coverage
  require('@bahmutov/cypress-code-coverage/plugin')(on, config)

  return config
}

`

I have installed the Istanbul plugin and cypress-code-coverage plugin for instrumentation and code coverage resepectively.

lmiller1990 commented 1 year ago

Does adding/removing

require('@bahmutov/cypress-code-coverage/plugin')(on, config)

change anything?

rgoyalmw commented 1 year ago

@lmiller1990 I tried removing the code coverage plugin. The pipeline still fails.

YevhenOpenup commented 1 year ago

The temporary solution is to downgrade to 12.6.0 and if you are using Vite as a builder, downgrade it to 4.1.5.

lmiller1990 commented 1 year ago

12.6.0

Soooo 12.7 broke something?? This is extremely useful info, is this consistent for you?

kevinearldenny commented 11 months ago

@nagash77 Is this fixed in Cypress 13?

cypress-io / cypress