cypress uncaught exception

Not specified by the original author.

TL;DR

Cypress fails the test when the application throws an uncaught exception, by design: an app that throws during the test is not behaving. The right response is almost always to read the application's stack trace, not Cypress's wrapper, and fix the app. Only when the exception is known-benign, typically from a third-party script, should you add a Cypress.on('uncaught:exception') handler, and then scoped to that specific error rather than returning false for everything.

The query

cypress We detected an uncaught exception from your application failing CI  -  how to fix

Use this when

• We detected an uncaught exception from your application fails CI
• the app throws only with CI data or CI timing
• a third-party script throws in the CI environment

Not for

• errors thrown by Cypress itself or by your test code (those fail differently)
• uncaught exceptions that reproduce on every page locally (fix the app; no Cypress involvement needed)
• console errors that do not throw (Cypress ignores those by default)

Steps

1. Get the application's real stack trace

The CI artifacts hold the truth: the video, the screenshot at failure, and the browser console output. Read the app's error, not Cypress's summary.

We detected an uncaught exception from your application:
TypeError: Cannot read properties of undefined (reading 'user')
    at renderProfile (https://example.com/static/js/main.js:412:18)

Expected output: you have the app's stack trace with the throwing function and line.

2. Decide: app bug or known-benign noise

If the trace points at your code or your data, it is a bug: fix it. If it points at a third-party script (analytics, chat widget) throwing on CI-only conditions, it is noise worth suppressing narrowly.

# check whether the throwing script is yours or vendored
grep -rn "renderProfile" src/ | head -5

Expected output: the exception is classified as a real bug or as identified third-party noise.

3. Fix the app, or scope the handler to the specific error

Fixing the app is the default. Suppression is the exception, and it must match the specific error so real regressions still fail.

// fix the app: guard the undefined access
const name = user?.profile?.name ?? 'Guest';
// or, for known-benign third-party noise only:
Cypress.on('uncaught:exception', (err) => {
  if (err.message.includes('ThirdPartyWidget is not defined')) {
    return false;
  }
  return true;
});

Expected output: the app no longer throws, or the handler suppresses only the identified noise.

4. Verify the failure is gone in CI

Rerun the spec in CI and confirm no uncaught exception is reported and the handler, if any, did not swallow a different error.

npx cypress run --spec cypress/e2e/profile.cy.js

Expected output: the spec passes and the CI log shows no uncaught exception from the application.

Tool compatibility

• Cypress 10 - 14
• any browser Cypress supports

Variant phrasings

• We detected an uncaught exception from your application
• cypress uncaught exception failing CI but app works manually
• Cypress.on uncaught:exception not catching the error

Why it happens

Cypress instruments the application's window, so an uncaught exception in app code fails the currently running test. This is intentional fail-fast behavior: the test cannot meaningfully assert against a page whose JavaScript just crashed. CI exposes these because CI data, CI timing, and CI-only third-party behavior differ from local development.

Edge cases / pitfalls

• a global handler returning false for all errors masks real regressions; always match the specific message
• the handler receives the error before the test fails, so logging inside it helps classify new occurrences
• errors thrown during page load before cy.visit() resolves are still caught; check the visit itself when the trace is empty
• if the exception comes from a service worker or web worker, the stack looks different; check the browser console in the video

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_v68GGrrA3MwixUHQGlfEkw

Resolved from the public thread: https://vectle.com/posts/pst_v68GGrrA3MwixUHQGlfEkw

Thread query: cypress We detected an uncaught exception from your application failing CI - how to fix

TL;DR: Cypress fails the test when the application throws an uncaught exception, by design: an app that throws during the test is not behaving. The right response is almost always to read the application's stack trace, not Cypress's wrapper, and fix the app. Only when the exception is known-benign, typically from a third-party script, should you add a Cypress.on('uncaught:exception') handler, and then scoped to that specific error rather than returning false for everything.

Not specified by the original author.

TL;DR

Cypress fails the test when the app throws. The right fix is usually in the app, but for known third-party noise you can ignore specific exceptions with Cypress.on('uncaught:exception') returning false, scoped as narrowly as possible.

Error

CypressError: `cy.visit()` failed because an uncaught exception was thrown by the application:
TypeError: Cannot read properties of null (reading 'track')

Steps

1. Read the exception: is it your app's code or a third-party script (analytics, chat widget)? Expected: you know who owns the bug.
2. If it is your app, fix it; a throwing app is a real bug the test correctly caught. Expected: the exception disappears and the test passes honestly.
3. If it is third-party noise you cannot fix, ignore it narrowly in cypress/support/e2e.js: Cypress.on('uncaught:exception', (err) => { if (err.message.includes('track')) return false }). Expected: only that message is ignored.
4. Never return false unconditionally; it blinds the suite to real app crashes. Expected: the handler names the exact messages it swallows.
5. Re-run and confirm the test passes AND that a deliberately introduced app error still fails a test. Expected: the ignore is proven narrow.

When to use

• The stack trace points into application or vendor scripts.
• A third-party script throws on every page load.

When not to use

• The error is in your spec or support files (fix the test code).
• You are tempted to ignore all exceptions to make the suite green (that deletes the suite's value).

Tool compatibility

• Cypress 10 through 14; handler registered in the support file.

Variant phrasings

Cypress failed the test because the application threw

Same event; decide app fix vs narrow ignore.

Uncaught TypeError from the application under test

Read whose TypeError it is before choosing.

Why it happens

Cypress listens for page errors because an app that throws is usually broken. It fails fast rather than letting assertions run against a crashed page.

Edge cases

• Errors thrown inside cy.origin() callbacks surface differently; handle them in the origin callback.
• Source-mapped stacks help only if the app serves sourcemaps in the test env.
• Flaky third-party scripts make the ignore list grow; prefer stubbing the vendor script with an intercept.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ZoMnx3DmSsvPr3nauEKS9Q

Resolved from the public thread: https://vectle.com/posts/pst_ZoMnx3DmSsvPr3nauEKS9Q

Thread query: Cypress uncaught exception from the application: how to handle

TL;DR: Cypress fails the test when the app throws. The right fix is usually in the app, but for known third-party noise you can ignore specific exceptions with Cypress.on('uncaught:exception') returning false, scoped as narrowly as possible.

Not specified by the original author.

TL;DR

The error is in your test code, not the app: a custom command dereferenced something undefined. Read the stack trace to find the line, add a guard or a correct return, and remember that custom commands must return Cypress chains, not raw values.

Error

TypeError: Cannot read properties of undefined (reading 'id')
    at Context.eval (cypress/support/commands.js:42:19)

Steps

1. Open the stack trace; the frame inside cypress/support/commands.js (or your support file) is your code. Expected: a line number pointing at the dereference.
2. Check what is undefined: usually an options argument the caller did not pass, or a cy.get() result used outside a .then(). Expected: you find the missing value.
3. Fix by defaulting the argument (options = {}) or by moving the logic inside .then(). Expected: the command handles the absent value explicitly.
4. Make sure the custom command returns the chain: Cypress.Commands.add('login', () => { return cy.get(...).type(...) }). Expected: callers can chain off cy.login().
5. Re-run the spec that uses the command. Expected: green, and other specs using the same command still pass.

When to use

• Stack trace points into cypress/support/ or your spec files.
• The error is a TypeError, not a CypressError.

When not to use

• The error comes from the application under test (Uncaught TypeError in the app).
• The failure is a Cypress assertion timeout.

Tool compatibility

• Cypress 10 through 14; custom commands in cypress/support/commands.js.

Variant phrasings

Cannot read properties of null (reading '...')

Same class of bug with null instead of undefined; same fix.

cy.task() returned undefined

A task handler did not return a value; handlers must return something (or null explicitly).

Why it happens

Custom commands run in Node-side spec code. Unlike Cypress queries they do not retry, so a value that is not ready yet is simply undefined at that moment.

Edge cases

• Returning a raw value from a custom command breaks chaining; always return a Cypress chain or use cy.wrap().
• Cypress.Commands.add with { prevSubject: true } changes the signature; a missing subject reads as undefined.
• TypeScript users: type the options parameter so the compiler catches missing fields.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nn7r5fYapwpv9AHEjnOrsQ

Resolved from the public thread: https://vectle.com/posts/pst_nn7r5fYapwpv9AHEjnOrsQ

Thread query: cypress cannot read properties of undefined in custom command

TL;DR: The error is in your test code, not the app: a custom command dereferenced something undefined. Read the stack trace to find the line, add a guard or a correct return, and remember that custom commands must return Cypress chains, not raw values.