feat: improve stability when recording#25837
Conversation
3 flaky tests on run #44406 ↗︎Details:
|
|||||||||||||||||||||||||||
| 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.
- 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
| }, | ||
|
|
||
| preflight (preflightInfo) { | ||
| postPreflight (preflightInfo) { |
There was a problem hiding this comment.
this was renamed to postPreflight but there are several places preflight is referenced in this file.
There was a problem hiding this comment.
Seems like this should still be named preflight
There was a problem hiding this comment.
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.
On this diff view, there's
- where postFlight is called, the
preflightOptionsare passed in. - in this method, theres
preflightInfoandpreflightBaseProxyandpreflightResult, resetPreflightResult
There was a problem hiding this comment.
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.
ohh ha, teaches me to read it a bit closer. I was reading it as postFlight
ignore my suggestions
| if (response.headers['x-cypress-encrypted'] || params.encrypt === 'always') { | ||
| let decryptedBody | ||
|
|
||
| // TODO: if body is null/undefined throw a custom error |
There was a problem hiding this comment.
We should log issues for these TODO or they likely will get forgotten
There was a problem hiding this comment.
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.
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.
preflight wouldnt but thats not the only situation it could occur in
| if (response.headers['x-cypress-encrypted'] || params.encrypt === 'always') { | ||
| let decryptedBody | ||
|
|
||
| // TODO: if body is null/undefined throw a custom error |
There was a problem hiding this comment.
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
| } | ||
| }, | ||
|
|
||
| // TODO: i think we can remove this function |
There was a problem hiding this comment.
I don't think we can without reworking a lot of tests
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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.
i understand that, i'm solving for a different scenario
|
|
||
| // 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.
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.
yeah i worked my way through everything else, so that's the last system test to look at to verify that functionality/behavior
| resource_class: macos.x86.medium.gen2 | ||
| requires: | ||
| - darwin-x64-build | ||
| - server-unit-tests-cloud-environment: |
There was a problem hiding this comment.
How come this job isn't run against darwin-arm64 and linux-arm64?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Does this still need to be done?
| 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.
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.
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.
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.
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.
Updated here with cleaner logic: 802f193 (#25837)
-throw proper status code error - properly unroll transform errors - add tests
…into fix/preflight
… 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?