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

feat: improve stability when recording #25837

Merged
merged 58 commits into from
Feb 24, 2023
Merged

feat: improve stability when recording #25837

merged 58 commits into from
Feb 24, 2023

Conversation

brian-mann
Copy link
Member

@brian-mann brian-mann commented Feb 16, 2023

Additional details

This PR improves various error messages around interactions with the Cypress cloud and fixes various bugs when recording to the cloud.

Steps to test

This can be tested by recording test runs to the cloud and ensuring there are no problems. The specific edge case error scenarios are thoroughly tested in the tests on this PR.

How has the user experience changed?

n/a

PR Tasks

@cypress
Copy link

cypress bot commented Feb 16, 2023

3 flaky tests on run #44406 ↗︎

0 5116 74 0 Flakiness 3

Details:

added tests for failing after preflight, but valid decryption, always fail on 41...
Project: cypress Commit: 45c8a33f1c
Status: Passed Duration: 13:41 💡
Started: Feb 24, 2023 9:54 PM Ended: Feb 24, 2023 10:07 PM
Flakiness  cypress/e2e/cypress/cypress.cy.js • 3 flaky tests • 5x-driver-electron

View Output Video

Test
... > correctly returns currentRetry
... > correctly returns currentRetry
... > correctly returns currentRetry

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

@brian-mann brian-mann changed the title fix: recordings failing fix: improve stability when recording Feb 16, 2023
@@ -452,23 +465,40 @@ module.exports = {
responseCache = {}
},

preflight (preflightInfo) {
postPreflight (preflightInfo) {
Copy link
Member

@emilyrohrbough emilyrohrbough Feb 16, 2023

Choose a reason for hiding this comment

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

this was renamed to postPreflight but there are several places preflight is referenced in this file.

Copy link
Member

Choose a reason for hiding this comment

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

Seems like this should still be named preflight

Copy link
Member Author

Choose a reason for hiding this comment

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

where is it referenced? all of the other methods are verbs, so I just renamed it to make it consistent

Copy link
Member

Choose a reason for hiding this comment

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

On this diff view, there's

  • where postFlight is called, the preflightOptions are passed in.
  • in this method, theres preflightInfo and preflightBaseProxy and preflightResult,
  • resetPreflightResult

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah i gotcha... but all that makes sense... the verb (action) uses postPreflight to act as a similar pattern to how we do all functions as verbs... whereas the object it takes (is basically the discrete payload/noun)... i see it like this

brian.sendsMessageTo(emily, emilyMsgInfo)

Copy link
Member

@emilyrohrbough emilyrohrbough Feb 16, 2023

Choose a reason for hiding this comment

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

ohh ha, teaches me to read it a bit closer. I was reading it as postFlight

ignore my suggestions

let decryptedBody

// TODO: if body is null/undefined throw a custom error
Copy link
Member

Choose a reason for hiding this comment

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

We should log issues for these TODO or they likely will get forgotten

Copy link
Member Author

@brian-mann brian-mann Feb 16, 2023

Choose a reason for hiding this comment

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

i will address/remove them all by the time this PR is done... they are notes in the places that I still have work to finish... the PR isn't done yet, I moved it to draft

Copy link
Member

@tgriesser tgriesser Feb 16, 2023

Choose a reason for hiding this comment

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

FWIW, this shouldn't ever be a valid scenario. Either we send a body or we don't send the response header indicating it needs to be processed. Preflight wouldn't have an empty body

Copy link
Member Author

Choose a reason for hiding this comment

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

preflight wouldnt but thats not the only situation it could occur in

@brian-mann brian-mann marked this pull request as draft February 16, 2023 14:49
let decryptedBody

// TODO: if body is null/undefined throw a custom error
Copy link
Member

@tgriesser tgriesser Feb 16, 2023

Choose a reason for hiding this comment

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

FWIW, this shouldn't ever be a valid scenario. Either we send a body or we don't send the response header indicating it needs to be processed. Preflight wouldn't have an empty body

@@ -244,11 +256,11 @@ module.exports = {
}
},

// TODO: i think we can remove this function
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we can without reworking a lot of tests

Copy link
Member Author

Choose a reason for hiding this comment

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

i basically already did that, haha... but its nbd, just leaving myself a note if I get it for free at the end as a reminder

// we failed decrypting the response...

// if status code is >=500 or 404 just return body
if (statusCode >= 500 || statusCode === 404 || statusCode === 422) {
Copy link
Member

Choose a reason for hiding this comment

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

We don't ever respond to /preflight with a 404 so it doesn't seem like would ever happen in real world use.

Copy link
Member Author

Choose a reason for hiding this comment

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

i understand that, i'm solving for a different scenario

throw new DecryptionError(e.message)
}

// If we've hit an encrypted payload error case, we need to re-constitute the error
// as it would happen normally, with the body as an error property
// TODO: need to look harder at this to better understand why its necessary
Copy link
Member

Choose a reason for hiding this comment

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

You'll see in the system tests if you remove this if block why it's needed. I believe it's because without it you'll get the original body in the StatusCodeError if you don't

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah i worked my way through everything else, so that's the last system test to look at to verify that functionality/behavior

@ryanthemanuel ryanthemanuel marked this pull request as ready for review February 24, 2023 15:19
@@ -2740,6 +2764,12 @@ darwin-x64-workflow: &darwin-x64-workflow
resource_class: macos.x86.medium.gen2
requires:
- darwin-x64-build
- server-unit-tests-cloud-environment:
Copy link
Contributor

Choose a reason for hiding this comment

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

How come this job isn't run against darwin-arm64 and linux-arm64?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I suppose I could add it. I'm not sure there's much benefit as the logic is platform specific, not architecture specific

})
})

// TODO: finish implementing this test
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this still need to be done?

Comment on lines 95 to 109
try {
const packageJsonPath = resolvePackagePath(dependency, projectRoot)

if (packageJsonPath) {
packageToJsonMapping[dependency] = packageJsonPath
checkProcessTree = true
}
} catch (error) {
errors.push({
dependency,
name: error.name,
message: error.message,
stack: error.stack,
})
}
Copy link
Member

Choose a reason for hiding this comment

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

seems like this callback is duplicated below? can we share a function between them? (or am i missing a difference?)

Copy link
Collaborator

Choose a reason for hiding this comment

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

The difference is setting checkProcessTree to true vs. false. I can see if I can share some of this though.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Updated here with cleaner logic: 802f193 (#25837)

Comment on lines 103 to 108
errors.push({
dependency,
name: error.name,
message: error.message,
stack: error.stack,
})
Copy link
Member Author

Choose a reason for hiding this comment

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

might want to refactor this into a common function since it does the same thing as lines 121-126 below

Copy link
Collaborator

Choose a reason for hiding this comment

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

Updated here with cleaner logic: 802f193 (#25837)

@ryanthemanuel ryanthemanuel changed the title fix: improve stability when recording feat: improve stability when recording Feb 24, 2023
-throw proper status code error
- properly unroll transform errors
- add tests
… fail on 412 preflight

- updated [W1] warning test case
- updated unit test cases names
@ryanthemanuel ryanthemanuel merged commit 2a17efa into develop Feb 24, 2023
@ryanthemanuel ryanthemanuel deleted the fix/preflight branch February 24, 2023 22:32
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.

None yet

7 participants