Skip to content
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

test: fix flaky migration test #25672

Merged
merged 4 commits into from
Feb 5, 2023
Merged

Conversation

ZachJW34
Copy link
Contributor

@ZachJW34 ZachJW34 commented Feb 1, 2023

Closes #25377

Additional details

Changes how the Migration flow is kicked off. Before, it was invoked when a project was clicked which lead to an initial query loading with null values. Now, the query is what kicks off the migration.

Most of the optimizations are around reducing the number of toLaunchpad calls the app was making, causing the query to re-execute multiple times.

It was hard to reproduce this failure locally as it seems to be influenced by machine resources.

Steps to test

Run the migrations.cy.ts e2e test in Launchpad

How has the user experience changed?

Screenshots show a reduced number of the migration query

Screen Shot 2023-02-01 at 1 26 07 PM

Screen Shot 2023-02-01 at 1 31 21 PM

PR Tasks

  • Have tests been added/updated?
  • Has the original issue (or this PR, if no issue exists) been tagged with a release in ZenHub? (user-facing changes only)
  • Has a PR for user-facing changes been opened in cypress-documentation?
  • Have API changes been updated in the type definitions?

@cypress
Copy link

cypress bot commented Feb 1, 2023

Passing run #43800 ↗︎

0 565 0 0 Flakiness 0

Details:

Merge branch 'develop' into zachw/fix-flaky-migration-test
Project: cypress Commit: 5aa6c1a86b
Status: Passed Duration: 07:20 💡
Started: Feb 5, 2023 9:23 PM Ended: Feb 5, 2023 9:30 PM

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings.

@emilyrohrbough emilyrohrbough changed the title test: fix flaky migration test [run ci] test: fix flaky migration test Feb 1, 2023
Copy link
Contributor

@lmiller1990 lmiller1990 left a comment

Choose a reason for hiding this comment

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

Quick question before doing an in depth review

@@ -103,6 +103,11 @@ export class ProjectLifecycleManager {

async getProjectId (): Promise<string | null> {
try {
// No need to kick off config initialization if we need to migrate
if (this.ctx.migration.needsCypressJsonMigration()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

General question - if the test is only flaky, I wouldn't expect we need to touch production code to fix it. WDYT? Is there any additional risk here? Is the test hitting a scenario that's impossible in prod?

Copy link
Contributor

Choose a reason for hiding this comment

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

Or is this just a general QOL improvement since it's purely optimizations?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think this test was particularly flaky because it migrated two projects, and the number of queries re-executed was doubled/tripled. Hard to reproduce locally but in slow CI environments I think a call might have been dropped in between states and caused the test to fail.

I don't think there is a fix for this outside touching production code. The number of requeries is a sign we aren't doing something correct so most of the changes was to reduce this behavior.

Copy link
Contributor

Choose a reason for hiding this comment

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

if the test is only flaky, I wouldn't expect we need to touch production code to fix it. WDYT?

I see this a bit differently, a flaky test is often telling us about non-determinism in the app code that we don't see locally due to different system resources, OS, etc.

Copy link
Contributor

@lmiller1990 lmiller1990 left a comment

Choose a reason for hiding this comment

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

If CI is good this is fine, just some question questions - I'll approve as no to block this for too long, not wanting to spend too much time on flaky fix - quick fix is a good fix

// Only call "to{App,Launchpad}" once the config is done loading.
// Calling this in a "finally" would trigger this emission for every
// call to get the config (which we do a lot)
this.options.ctx.emitter.toLaunchpad()
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice, I noticed we have a lot of excess gql calls in general, hope we can find a good way to monitor/track these eventually... no idea how other apps handle this, or do they just have lots of requests 🤔

Nice thing about REST is you are very deliberate about requests - just thinking out loud here, gql sure is nice but man it has some trade-offs (complexity, hard to really know what/when a call is triggered).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it all boils down the the toLaunchpad calls. This causes every active query to retrigger. If properly designed, we could probably get away with removing this altogether. Or we could rely more heavily on subscriptions to update data.

@@ -103,6 +103,11 @@ export class ProjectLifecycleManager {

async getProjectId (): Promise<string | null> {
try {
// No need to kick off config initialization if we need to migrate
if (this.ctx.migration.needsCypressJsonMigration()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

if the test is only flaky, I wouldn't expect we need to touch production code to fix it. WDYT?

I see this a bit differently, a flaky test is often telling us about non-determinism in the app code that we don't see locally due to different system resources, OS, etc.

packages/launchpad/cypress/e2e/migration.cy.ts Outdated Show resolved Hide resolved
@marktnoonan marktnoonan merged commit 3040304 into develop Feb 5, 2023
@marktnoonan marktnoonan deleted the zachw/fix-flaky-migration-test branch February 5, 2023 22:57
tgriesser added a commit that referenced this pull request Feb 8, 2023
* develop: (28 commits)
  chore: update changelog validation example (#25742)
  fix: Improve error handling around calls to `this.next` in middleware (#25702)
  chore: debug page tooltip distance and artifact border (#25727)
  fix: update newProject ref when switching between organizations in SelectCloudProjectModal (#25730)
  misc: Add max widths to debug page message states (#25725)
  chore: export types (#25714)
  chore: release @cypress/webpack-preprocessor-v5.16.3
  chore: release @cypress/vue-v5.0.4
  chore: release @cypress/grep-v3.1.4
  chore: Fix flaky test (#25726)
  dependency(deps): update dependency debug to ^4.3.4 🌟 (#25699)
  feat: openInIDE for failed debug spec (#25691)
  test: fix flaky CT test by relying on query (#25706)
  test: fix flaky migration test (#25672)
  misc: style change for responsiveness (#25687)
  misc: set min widths for icons (#25684)
  chore(deps): update dependency markdown-it to v11.0.1 🌟 (#25698)
  chore: Fix flaky origin .wait() test (#25693)
  chore: unskip tests (#25676)
  chore: release @cypress/webpack-preprocessor-v5.16.2
  ...
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.

Flaky test: migrates 2 projects in global mode
3 participants