-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Conversation
3 flaky tests on run #44406 ↗︎
Details:
cypress/e2e/cypress/cypress.cy.js • 3 flaky tests • 5x-driver-electron
This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. |
- made some errors clearer - moved up server response errors to be closer to the error, instead of pushed down by list items - renamed old usage of "Desktop App" to "Cypress app" - updated on links referring to the dashboard -> cloud
packages/server/lib/cloud/api.ts
Outdated
@@ -452,23 +465,40 @@ module.exports = { | |||
responseCache = {} | |||
}, | |||
|
|||
preflight (preflightInfo) { | |||
postPreflight (preflightInfo) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
andpreflightBaseProxy
andpreflightResult
, resetPreflightResult
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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
packages/server/lib/cloud/api.ts
Outdated
let decryptedBody | ||
|
||
// TODO: if body is null/undefined throw a custom error |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
packages/server/lib/cloud/api.ts
Outdated
let decryptedBody | ||
|
||
// TODO: if body is null/undefined throw a custom error |
There was a problem hiding this comment.
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
packages/server/lib/cloud/api.ts
Outdated
@@ -244,11 +256,11 @@ module.exports = { | |||
} | |||
}, | |||
|
|||
// TODO: i think we can remove this function |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
packages/server/lib/cloud/api.ts
Outdated
// we failed decrypting the response... | ||
|
||
// if status code is >=500 or 404 just return body | ||
if (statusCode >= 500 || statusCode === 404 || statusCode === 422) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
packages/server/lib/cloud/api.ts
Outdated
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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
@@ -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: |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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
packages/server/test/support/fixtures/cloud/environment/.gitignore
Outdated
Show resolved
Hide resolved
}) | ||
}) | ||
|
||
// TODO: finish implementing this test |
There was a problem hiding this comment.
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?
packages/server/test/support/fixtures/cloud/environment/test-project/package.json
Outdated
Show resolved
Hide resolved
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, | ||
}) | ||
} |
There was a problem hiding this comment.
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?)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
errors.push({ | ||
dependency, | ||
name: error.name, | ||
message: error.message, | ||
stack: error.stack, | ||
}) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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)
-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
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-documentation
?type definitions
?