Skip to content

Conversation

cacieprins
Copy link
Contributor

@cacieprins cacieprins commented Oct 2, 2025

Additional details

Adds 112 as a potential exit code when Cypress is run with POSIX complaint exit codes enabled (--posix-exit-codes). This exit code is used when --record or --parallel mode is unable to communicate with Cypress Cloud API due to network conditions.

Steps to test

How has the user experience changed?

PR Tasks


Note

Adds POSIX exit code 112 when Cloud network errors block recorded/parallel runs, introduces network-specific error types/messages, makes Cloud API timeouts configurable, and updates tests/snapshots accordingly.

  • Run/Exit Codes (POSIX):
    • Exit with code 112 when --posix-exit-codes is enabled and Cloud network errors prevent proceeding in recorded (--record) or parallel (--parallel) runs.
  • Errors & Schema:
    • New errors: CLOUD_CANNOT_PROCEED_IN_PARALLEL_NETWORK and CLOUD_CANNOT_PROCEED_IN_SERIAL_NETWORK with tailored messaging; added to schema.graphql and errors.ts plus snapshots.
  • Server/CLI:
    • Map Cloud network failures to the new error types; revise startInMode/exitErr flow to emit code 112 for these errors; remove modes/exit.ts and inline handling.
    • Prefer 64‑bit browsers note left intact; add debug logging and minor refactors.
  • Cloud API:
    • Make request timeouts configurable via CYPRESS_INTERNAL_API_TIMEOUT; use as default across Cloud API calls.
  • Stability:
    • Tweak early-exit handling signature; minor refactors.
  • Tests:
    • Add/adjust integration and system tests (and snapshots) for new errors, exit code 112, configurable timeouts, and messaging; update changelog for 15.5.0.

Written by Cursor Bugbot for commit 4152a21. This will update automatically on new commits. Configure here.

Copy link

cypress bot commented Oct 2, 2025

cypress    Run #66384

Run Properties:  status check failed Failed #66384  •  git commit 4152a21977: Merge branch 'develop' into feat-api-failure-exit-112
Project cypress
Branch Review feat-api-failure-exit-112
Run status status check failed Failed #66384
Run duration 18m 33s
Commit git commit 4152a21977: Merge branch 'develop' into feat-api-failure-exit-112
Committer Cacie Prins
View all properties for this run ↗︎

Test results
Tests that failed  Failures 7
Tests that were flaky  Flaky 5
Tests that did not run due to a developer annotating a test with .skip  Pending 1018
Tests that did not run due to a failure in a mocha hook  Skipped 4
Tests that passed  Passing 19973
View all changes introduced in this branch ↗︎

Warning

Partial Report: The results for the Application Quality reports may be incomplete.

UI Coverage  44.99%
  Untested elements 187  
  Tested elements 157  
Accessibility  97.97%
  Failed rules  4 critical   8 serious   2 moderate   2 minor
  Failed elements 101  

Tests for review

Failed  commands/waiting.cy.js • 0 failed tests • 5x-driver-electron

View Output

Test Artifacts
Failed  cypress/cy.cy.js • 0 failed tests • 5x-driver-electron

View Output

Test Artifacts
Failed  commands/command_option_immutability.cy.js • 0 failed tests • 5x-driver-electron

View Output

Test Artifacts
Failed  e2e/origin/navigation.cy.ts • 0 failed tests • 5x-driver-electron

View Output

Test Artifacts
Failed  commands/actions/submit.cy.ts • 0 failed tests • 5x-driver-electron

View Output

Test Artifacts

The first 5 failed specs are shown, see all 623 specs in Cypress Cloud.

Flakiness  e2e/origin/cookie_login.cy.ts • 1 flaky test • 5x-driver-firefox

View Output

Test Artifacts
... > past Max-Age, before Expires -> not logged in
    </td>
  </tr></table>
Flakiness  commands/files.cy.js • 1 flaky test • 5x-driver-firefox

View Output

Test Artifacts
src/cy/commands/files > #readFile > retries to read when ENOENT
    </td>
  </tr></table>
Flakiness  commands/net_stubbing.cy.ts • 1 flaky test • 5x-driver-firefox

View Output

Test Artifacts
... > stops waiting when an xhr request is canceled
    </td>
  </tr></table>
Flakiness  e2e/origin/config_env.cy.ts • 1 flaky test • 5x-driver-firefox

View Output

Test Artifacts
cy.origin- Cypress.config() > serializable > overwrites different values in secondary if one exists in the primary
    </td>
  </tr></table>
Flakiness  e2e/origin/config_env.cy.ts • 1 flaky test • 5x-driver-inject-document-domain-chrome

View Output

Test Artifacts
cy.origin- Cypress.config() > serializable > overwrites different values in secondary if one exists in the primary Test Replay

@cacieprins cacieprins marked this pull request as ready for review October 7, 2025 20:23
@cacieprins cacieprins marked this pull request as draft October 7, 2025 20:23
cursor[bot]

This comment was marked as outdated.

@cacieprins cacieprins marked this pull request as ready for review October 8, 2025 13:15
cursor[bot]

This comment was marked as outdated.

@cacieprins cacieprins requested a review from AtofStryker October 8, 2025 13:52
return require('./errors').logException(err)
.then(() => {
debug('calling exit 1')
await require('./errors').logException(err)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any reason we can just import errors at the top of the file since we are starting to move away from CJS?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because of how the integration tests are set up, this has to be dynamically required for now :(

break
}
case 'returnPkg': {
const pkg = await require('./modes/pkg')(options)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we just import pkg from '@packages/root' at the top of the file since its a bundled package now and just reference it here instead of ./modes/pkg? Would be much simpler

break
}
case 'info': {
await require('./modes/info')(options)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we just hoist this import or await import it? If not I'll likely get to this in the launcher refactor

})
})

it('errors and exits with 1 when posix exit codes are enabled', function () {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whats the reason the posix tests are added here and not in the posix PR? Is there some type of integration between these two I am missing?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh I see its the differences between 112 vs 1 exit code

@@ -0,0 +1,8 @@
We encountered an unexpected error communicating with our servers.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is so much easier to diff now

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It really really is!

@jennifer-shehane jennifer-shehane self-requested a review October 8, 2025 20:22
cli/CHANGELOG.md Outdated

**Features:**

- When the `run` command requires successful negotiation with the Cypress Cloud API and the `--posix-exit-codes` flag is set, Cypress will now exit with code `112` when it cannot determine which spec to run next due to network conditions. These Cloud API negotiations are required when either `--record` or `--parallel` flags are set. Addresses [#32485](https://github.com/cypress-io/cypress/issues/32485). Addressed in [#32635](https://github.com/cypress-io/cypress/pull/32635).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- When the `run` command requires successful negotiation with the Cypress Cloud API and the `--posix-exit-codes` flag is set, Cypress will now exit with code `112` when it cannot determine which spec to run next due to network conditions. These Cloud API negotiations are required when either `--record` or `--parallel` flags are set. Addresses [#32485](https://github.com/cypress-io/cypress/issues/32485). Addressed in [#32635](https://github.com/cypress-io/cypress/pull/32635).
- When `cypress run` is run with the `--record` or `--parallel` flags and the `--posix-exit-codes` flag is set, Cypress will now exit with code `112` when it cannot determine which spec to run next due to network conditions. Addresses [#32485](https://github.com/cypress-io/cypress/issues/32485). Addressed in [#32635](https://github.com/cypress-io/cypress/pull/32635).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the CLI docs https://docs.cypress.io/app/references/command-line, these are called "options" rather than "flags"

record, or record AND parallel are valid choices, parallel on its own is an error condition - see https://docs.cypress.io/app/references/error-messages#The---ci-build-id---group---tag---parallel-or---auto-cancel-after-failures-flags-can-only-be-used-when-recording so you don't even need to mention it.

Suggest:
When cypress run is used with the --record option together with the --posix-exit-codes option ...

}
}

debug('calling exit 1')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can remove I believe

}
debug('end of startInMode, exit 0')

return exit(0)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to have an 'exitErr'? We used to have handling of this here. I'm not sure when this would happen.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The exitErr is in the catch block above - this would get hit when one of the switch cases that doesn't return is hit (e.g., info).

Before, every switch case returned a promise, even if they didn't need to (this is an old-style way of preventing the Zalgo effect that is rendered obsolete with async/await).

Comment on lines 14 to 15
import { getError, AllCypressErrorNames } from '@packages/errors'

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
import { getError, AllCypressErrorNames } from '@packages/errors'
import { getError } from '@packages/errors'
import type { AllCypressErrorNames } from '@packages/errors'

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in 660ab1b

})
default:
return throwErr('CLOUD_UNKNOWN_INVALID_REQUEST', {
throw throwErr('CLOUD_UNKNOWN_INVALID_REQUEST', {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not understanding why this would change to throw either.

})
})

it('exits with code 1 for parallel cloud API failures when posix-exit-codes is enabled', function () {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This title is incorrect

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

title was correct, assertion was wrong ;) addressed in 3f096f2

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

UX/CLI Improvement: Fatal Cy Cloud communication failure exits with a specific exit code

4 participants