fix: Launchpad perpetual loading state, in certain circumstances

[cacieprins]

• Closes Flaky tests: Launchpad: Setup Project (project-setup.cy.ts) #29486

Additional details

This bug was evidenced by the flaky tests in the linked issue, but may have other manifestations that will clear up with this PR.

The currentProject schema on the MainLaunchpadQuery GraphQL query, used by Launchpad's Main.vue, has a field named isLoadingConfigFile. This is a boolean field, and both true and false fields are valid for it.

Previous to this PR, if this field was true for the first MainLaunchpadQuery request, the main launchpad UI would get stuck in a loading state: the rest of the launchpad cannot operate properly if the config file has not yet loaded, so we gate a lot of functionality behind that field.

In the linked flaky tests, we execute two custom tasks: scaffoldProject and openProject.

scaffoldProject initializes one of the projects from system-tests, and installs dependencies for it. openProject spawns the Cypress process that will execute against the scaffolded project, and initializes some data contexts. That kicks off the process that loads the config file, but the task does not wait for that loading to be complete before resolving. Sometimes the config file loads quickly - before the outer e2e runner can load the launchpad under test - and the flaky tests pass. Other times the config file loads during or just after the MainLaunchpadQuery request, which causes the flaky tests to fail - the inner loading spinner in Main.vue is never removed, because isLoadingConfigFile is false on first render of the query's data.

This is labeled as a fix rather than flake because this path, from what I can tell, is possible for end users to experience, though it is likely a rare occurrence.

The solution implemented is simply to poll (with a geometrically increasing delay) the MainLaunchpadQuery until the config file loads. This does not have a max count, because the baseError of this query is set up as a subscription - if the config file fails to load, the error gets propagated and the spinner is replaced with an error message.

Another option to consider would be to make config (and related fields in the @packages/graphql schema) a first-class type and resolver, where the root resolver would await the process of loading the config file. This was determined to be a fairly large change, however, when a simple poll would fix the manifestation of the bug.

Steps to test

Execute the config loading state block in @packages/launchpad's project-setup.cy.ts spec. The first request to the MainLaunchpadQuery resolves with isLoadingConfigFile: true, while the second request resolves with isLoadingConfigFile: false. Any subsequent calls will throw an error.

How has the user experience changed?

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?

[ryanthemanuel]

Do we want to have a test for the error scenario?

[cacieprins]

Addressed in c15a55d - thanks, it found a bug!

[cypress]

Passing run #55632 ↗︎

0

5560

73

0

0

Details:

Merge branch 'develop' into cacie/fix/launchpad-stuck-when-config-not-loaded
Project: cypress	Commit: 33d6f625cd
Status: Passed	Duration: 17:22 💡
Started: Jun 3, 2024 7:33 PM	Ended: Jun 3, 2024 7:50 PM

Review all test suite changes for PR #29597 ↗︎

[cypress-bot]

Released in 13.11.0.

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