internal: show loading and error statuses in studio panel, add download timeout

[astone123]

• Closes https://github.com/cypress-io/cypress-services/issues/10391

Additional details

This PR makes updates to the studio lifecycle to surface errors in a better way. Right now, if studio errors out or the user gets to it before it loads, we just don't show the Studio Beta button to open it. This can lead to some confusion in the user experience.

This PR makes the following changes:

• Convert studio GraphQL query into a subscription so that the UI can update with different studio statuses
• Add cloudStudioEnabled field so that the UI knows whether or not cloud studio is supposed to show up
• Always show Studio Beta button if cloudStudioEnabled
• Add INITIALIZING status for studio so that the UI can show a loading state if the user reaches studio before it is downloaded
• Add a 30-second (subject to change) timeout for fetching the studio bundle. If fetching studio takes more than 30 seconds, we'll put the studio manager in IN_ERROR status, and the UI will display an error in the panel letting the user know that there was an error loading studio.

Steps to test

I tested this by slowing my Mac's network connection down using Network Link Conditioner. I set my network to 1kbps download speed and opened Cypress and verified the following with cloud studio enabled:

• User is still able to navigate to a test, and the studio beta button will show regardless of whether or not studio has finished loading
• If the user opens the panel before studio has finished loading and before it times out, they will see the loading state
• Once the request times out for downloading studio, the user sees an error message

How has the user experience changed?

The user is able to open the cloud studio panel regardless of whether or not studio has finished downloading

PR Tasks

• Have tests been added/updated?
• [na] Has a PR for user-facing changes been opened in cypress-documentation?
• [na] Have API changes been updated in the type definitions?

[cypress]

cypress    Run #62414

Run Properties:   Passed #62414  •  0ed20359d3: fix test

Project	cypress
Branch Review	studio-error-handling
Run status	Passed #62414
Run duration	11m 11s
Commit	0ed20359d3: fix test
Committer	astone123
View all properties for this run ↗︎

---

Test results
Failures	0
Flaky	1
Pending	0
Skipped	0
Passing	685
View all changes introduced in this branch ↗︎

UI Coverage  37.62%
Untested elements	131
Tested elements	79

Accessibility  92.36%
Failed rules	3 critical   8 serious   1 moderate   1 minor
Failed elements	429

[Copilot]

Pull Request Overview

This PR improves the handling of the studio panel by adding loading and error states, integrating a new "INITIALIZING" status, and implementing a download timeout for fetching the studio bundle. Key changes include:

• Enhancements to the studio lifecycle status and error handling (e.g., adding the "INITIALIZING" status).
• Updates to both server and GraphQL layers to support real-time studio status changes.
• Adjustments in the UI and test suites to reflect the new studio loading behavior.

Reviewed Changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
packages/types/src/studio/index.ts	Added "INITIALIZING" status in studio status definitions.
packages/server/test/unit/cloud/api/studio/get_and_initialize_studio_manager_spec.ts	Updated tests to use the new "shouldEnableStudio" parameter and added a timeout test case.
packages/server/test/unit/StudioLifecycleManager_spec.ts	Added tests for cloudStudioEnabled and status tracking with the new "INITIALIZING" state.
packages/server/lib/project-base.ts	Changed logic to check cloudStudioEnabled instead of legacy env variable checks.
packages/server/lib/cloud/api/studio/get_and_initialize_studio_manager.ts	Added download timeout logic and new parameters to support it.
packages/server/lib/StudioLifecycleManager.ts	Improved status tracking and proxy setup to emit status changes asynchronously.
packages/graphql/src/schemaTypes/* & schemas/schema.graphql	Added subscription and query fields to expose studio status and cloudStudioEnabled.
packages/data-context/src/actions/DataEmitterActions.ts	Added a new emitter method for studioStatusChange.
packages/app/src/studio/StudioPanel.vue	Updated panel components to differentiate between loading, error, and normal states using the new statuses.
packages/app/src/runner/SpecRunnerOpenMode.vue	Integrated subscription to studio status changes and updated usage in UI components.
packages/app/cypress/e2e/studio/studio.cy.ts	Adjusted E2E tests for legacy vs. cloud studio UI behavior and loading state validation.

Comments suppressed due to low confidence (1)

packages/app/src/studio/StudioPanel.vue:53

• [nitpick] It may be beneficial to restrict the 'studioStatus' prop to a union type of the expected status values (e.g., 'INITIALIZING' | 'IN_ERROR' | 'ENABLED') rather than a generic string, enhancing type safety and clarity.

studioStatus: string | null

[mschile]

• Spike into Retry mechanism
  • Add a 'retry' button in the UI in this case - when clicked - the request would retry.

Have you given any thought into how this would work?

[ryanthemanuel]

With this, do we want to update onStudioInit to wait for the getStudio promise to finish if cloud studio is enabled? (i.e. we still would not wait for users out in the wild today).

[astone123]

• Spike into Retry mechanism

  • Add a 'retry' button in the UI in this case - when clicked - the request would retry.

Have you given any thought into how this would work?

@mschile yeah, basically we would make a mutation to call initialize on the studio lifecycle manager again. The studio status would go back to INITIALIZING which would show the loading state in the UI, we'd reach back out to the cloud, and then either go back to the IN_ERROR state (where they could retry again) or ENABLED.

The outstanding questions I have are:

1. How do we deal with listeners the second time around? Right now, if studio errors out we delete the listeners, but we wouldn't want to do that in case the user retries and it's successful.
2. When I did a local prototype for this, I was having issues with module federation refusing to request the module again if it failed the first time. I think there's a way around this but I'd need to look into it more

[astone123]

With this, do we want to update onStudioInit to wait for the getStudio promise to finish if cloud studio is enabled? (i.e. we still would not wait for users out in the wild today).

I'm not opposed to this, but I don't see how it would change the behavior here

[ryanthemanuel]

I ran this and noticed a couple of things. I added a 60 second delay (in code) to getting the studio bundle and when I go to Studio, I see the loading screen as expected, but I see this in the console:

and then studio AI is disabled:

Seems like we need to handle the studio init differently with this change: https://github.com/cypress-io/cypress/blob/develop/packages/server/lib/project-base.ts#L405

[astone123]

@ryanthemanuel I fixed this in 317f1e9 - the console error is expected, since we want to track how often people are opening studio when it hasn't loaded yet. But it should correctly enable AI access now

[cypress-bot]

Released in 14.4.0.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v14.4.0, please open a new issue.