Skip to content

internal: (studio) initialize cloud studio asynchronously #31469

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 24 commits into
base: develop
Choose a base branch
from

Conversation

astone123
Copy link
Contributor

@astone123 astone123 commented Apr 8, 2025

Additional details

We'd like to know how many people are using Cypress Studio today. This PR does a few things:

  • Always load cloud bundle for Studio (so that init event is captured)
  • Make Studio loading async so that it doesn't block project opening
  • Create StudioLifecycleManager to handle accessing Studio

Steps to test

Ensure that studio still loads correctly - the cloud studio panel should still load when you pass the correct environment variables, and it should not when these variables are not provided.

Check the tests that I added that verify that the cloud code to collect telemetry is always called when Studio loads even if AI is not enabled.

How has the user experience changed?

Users shouldn't notice any changes to how Studio works today - the external user experience should remain unchanged.

PR Tasks

@astone123 astone123 self-assigned this Apr 8, 2025
@astone123 astone123 changed the title feat: (studio) capture telemetry for studio initialization chore: (studio) capture telemetry for studio initialization Apr 8, 2025
@astone123 astone123 changed the title chore: (studio) capture telemetry for studio initialization chore: (studio) capture anonymous telemetry for studio initialization Apr 9, 2025
Copy link

cypress bot commented Apr 9, 2025

cypress    Run #61866

Run Properties:  status check passed Passed #61866  •  git commit 8e9c88390a: fix test
Project cypress
Branch Review 10501-studio-telemetry
Run status status check passed Passed #61866
Run duration 18m 39s
Commit git commit 8e9c88390a: fix test
Committer astone123
View all properties for this run ↗︎

Test results
Tests that failed  Failures 0
Tests that were flaky  Flaky 9
Tests that did not run due to a developer annotating a test with .skip  Pending 1232
Tests that did not run due to a failure in a mocha hook  Skipped 0
Tests that passed  Passing 32147
View all changes introduced in this branch ↗︎
UI Coverage  46.2%
  Untested elements 186  
  Tested elements 164  
Accessibility  92.71%
  Failed rules  3 critical   8 serious   2 moderate   2 minor
  Failed elements 888  

@astone123 astone123 changed the title chore: (studio) capture anonymous telemetry for studio initialization internal: (studio) capture anonymous telemetry for studio initialization Apr 18, 2025
@astone123 astone123 marked this pull request as ready for review April 18, 2025 18:32
@jennifer-shehane
Copy link
Member

@astone123 Lint is failing here

@astone123 astone123 changed the title internal: (studio) capture anonymous telemetry for studio initialization internal: (studio) initialize cloud studio asynchronously Apr 21, 2025
@astone123 astone123 requested a review from mschile April 22, 2025 17:26
@@ -164,7 +164,12 @@ export interface CoreDataShape {
cloudProject: CloudDataShape
eventCollectorSource: EventCollectorSource | null
didBrowserPreviouslyHaveUnexpectedExit: boolean
studio: StudioManagerShape | null
studioLifecycleManager?: {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Would it make sense to put this type in the @types package similar to StudioManagerShape. So that we can have that type enforced in both places it's effectively used?


if (studioManager.status === 'INITIALIZED') {
// Start studio manager initialization but don't block
const studioManagerPromise = getAndInitializeStudioManager({
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm wondering whether we could move this promise to be either part of the constructor for StudioLifecycleManager (so that it's not really mutable after its set). Or maybe even better, encapsulate this logic entirely inside of StudioLifecycleManager (but only if it's not super messy to do that).

Copy link
Contributor

@mabela416 mabela416 left a comment

Choose a reason for hiding this comment

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

Looks good and works locally

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.

5 participants