Cypress: Uncaught SyntaxError: Invalid or unexpected token happening out of nowhere in CI/CD

[andrewryan1906]

Current behavior:

All of a sudden, out of nowhere, all of my Cypress tests are failing when run in CircleCI, with the following:

Uncaught SyntaxError: Invalid or unexpected token

This error originated from your application code, not from Cypress.

When Cypress detects uncaught errors originating from your application it will automatically fail the current test.

This behavior is configurable, and you can choose to turn this off by listening to the 'uncaught:exception' event.

https://on.cypress.io/uncaught-exception-from-application

Because this error occurred during a 'before each' hook we are skipping the remaining tests in the current suite: 'Coupons'

This is happening across multiple Angular projects. I have no idea where to begin to even pinpoint the issue - when I run Cypress via cypress open, all of my tests run fine.

I'm suspicious it's one of the npm packages I updated in between deploys, so here's the package.json DIFF:

Desired behavior:

The builds should run properly both in headless mode in CircleCI and locally. If that doesn't work, at least give me more info so I can chase down the issue.

Steps to reproduce: (app code and test code)

• I check in my code
• CircleCI picks up the change and runs it
• I get the aforementioned error in the Cypress dashboard

This just started today.

Versions

Cypress 3.4.1, Chrome 65

[jennifer-shehane]

From the error message: This error originated from your application code, not from Cypress.

I would look into the changes from your packages, maybe remove each update until it breaks. But, there's no evidence that this is an issue with Cypress, so will need to close without a reproducible bug.

[andrewryan1906]

" But, there's no evidence that this is an issue with Cypress,"

Guys; if Cypress works for weeks at a time, and then all of a sudden starts spitting out this error, ONLY in CircleCI, and with no other information that can help me understand what the problem is or begin to troubleshoot, then it is BY DEFINITION an issue with Cypress. At the very least, I think it reasonable for the tool to provide helpful information that would allow me to start to locate the issue.

And - the fact that I cannot reproduce it locally is highly suspect.

Perhaps you've encountered this before? Or some hints or where it could be? I have about 200 packages... removing them 1 at a time to get to the bottom of this is not an ideal solution.

[jennifer-shehane]

The code that Cypress is running will not change day to day on your system - the binary is installed on your system. So unless you have updated the Cypress version (or perhaps you have a loose version check in your package.json that bumped Cypress from 3.4.0 to 3.4.1) it is impossible for an error to have been introduced one day by Cypress without a change to your application or test code. This is how I am accessing this as not a Cypress issue.
​
To track down the error though, which is the important part.

​Firstly, I would try to add some logging to get the full console error to print in the stdout. With the screenshot you provided, perhaps the full stack trace is not being printed to show where this error is being thrown. There is a great plugin available to print all console messaging to the stdout that I would install and have run during CI here: https://github.com/flotwig/cypress-log-to-output
​
After this, if the new console output is not clear as to where the error originated - as tedious as it may seem, you will have to narrow down the issue. I would try to:
​
​- narrow down the tests that run to the smallest reproducible amount that cause this error.
​- narrow down the code to the exact commit that caused this error. If there were multiple package updates in one commit, I would roll back the updates to find the exact package that caused the issue.

[andrewryan1906]

Jennifer,

First, keep in mind this error is _only_ happening in CircleCI - I can't reproduce it locally.

That being you said, I got that logging tool (helpful, was wanting something like that for a while - thanks) and installed it. I saw from the notes that it didn't work in Electon, so I upgraded to the Cypress 1.8 CircleCI Orb and changed the browser to Chrome.

Same failures, and when I look at the logs for each individual test, and the cumulative log in CircleCI, I see no additional information. I know it's running Chrome b/c I see this:

Warning: Cypress can only record videos when using the built in 'electron' browser.

You have set the browser to: 'chrome'

A video will not be recorded when using this browser.

What's also weird is that there are a couple of tests that DO pass, while the others fail. And they are the same tests... and there's nothing different about those tests, or those pages, that explain why they fail. I've spent a fair bit of time trying to narrow that down. But - upon further inspection, there's something odd about those tests:

1) Even though the Cypress dashboard claims they passed, there are no screenshots available
2) The video is clipped short - only a couple seconds, which makes it look like they didn't run

I'm pretty stumped here.

I know it's something central, because it's happening across all of my angular apps (I have 4), and happened at the same time.

But reverting the package.json and package-lock.json back to where they were 3 days ago, which should essentially get the system back to where it was dependency-wise, _doesn't work._

I can't get it to happen locally where I could observe it. I can't get any logging info from CircleCI/Cypress Dashboard to pinpoint the issue. No matter what I do, I can't get the build to work again, even in a less-than-ideal state, so I can work backwards to try and figure out the issue via trial and error.

I'm kind of stuck. Any other ideas/suggestions?

[andrewryan1906]

OK,

I have an update here that I hope will be useful.

First, I realized that simply reverting the package.json to a previous version and running npm i to update the package-lock would have no real effect b/c of semantic versioning (i.e., if I have a reference to sample-package pointing to ^1.0.750, changing the version back to ^1.0.700 would still cause the package manager to get version 1.0.750 at build time because of the caret in front of the version).

So, realizing that, I went back and pinned all of the packages to the version they were at the last time I had a good build (by removing the caret) and was able to get the Cypress tests working again.

The problem appears to be one of the Angular packages; the following Angular packages were upgraded automatically by npm to 8.2.0:

• @angular/animations
• @angular/common
• @angular/compiler
• @angular/core
• @angular/forms
• @angular/platform-browser
• @angular/platform-browser-dynamic
• @angular/router

and dev-dependencies:

• @angular/cli
• @angular/compiler-cli
• @angular/language-service

Knocking all of these packages back to 8.1.3 (except @nagular/animations, which I sent to 8.1.2) FIXES THE PROBLEM. I don't know what it is in these package that is causing Cypress to freak out, but its something.

For now, I'm keeping my versions pinned and hopefully someone will figure out why these versions are breaking Cypress, but ONLY in the environment provisioned by the CircleCI orb, and with no output.

[mitschmidt]

Encountered the same issue and solved it by using this approach:
https://github.com/cypress-io/cypress/issues/4042#issuecomment-487562075

[andrewryan1906]

Thanks @mitschmidt . I just went back and upgraded all my @angular modules to 8.2.5, and the problem no longer occurred anyway... so I think I'm good.

Thanks,
Andrew

[saas2813]

This error message really should include the exception caught and it's stacktrace otherwise failing in this way is worse than useless. I just had to update my Jenkins environment and suddenly got this message. Jenkins runs our tests with Docker so the access to system logs are rather limited and of-course it works on my own dev system even in headless mode and after npm update.

There are way too many "Heisenbug" false positives to chase down when working with Cypress and now I get this in my face, this is really not a dependable tool. Even the standard test-failures does not give enough info to track down the bug or even the file defining the failing test! With luck the screenshot covers the information. And of-course the actual Cypress-log is not available in the automated environment.