-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
fix: error regression - strip ansi colors out of cy.fixture() error message #20335
Conversation
Thanks for taking the time to open a PR!
|
Test summaryRun details
View run in Cypress Dashboard ➡️ Flakiness
This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
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.
Did a test need to be updated and/or added to ensure this is working as expected?
An existing test was modified to ensure the err.message had ansi stripped. No new test needed to be written. |
Actually don't merge this yet - I have one other area to check to ensure ANSI styles aren't leaking out. Has to do with config validation when providing overrides to the |
// the @packages/error list, it should be written in | ||
// the driver since this error can only occur within | ||
// driver commands and not outside of the test runner | ||
const err = errors.get('FIXTURE_NOT_FOUND', relativePath, extensions) |
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.
-
Would it make more sense to update the error to remove the ansi from the FIXTURE_NOT_FOUND error (it has a
// fix me
comment we can remove). -
I assume there is risk other errors created in the server that's sent back to the driver will also need to strip out asni? It seem like it'd be safer to add this logic to the reporter directly in the error component: https://github.com/cypress-io/cypress/blob/develop/packages/reporter/src/errors/test-error.tsx#L73
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.
That's what I was double checking - there is rarely a situation where we construct the error message in the server with ANSI styling AND send it through to the driver.
That's why I added the FIXME because there's no reason for the server to construct this error. The vast majority of the errors are formatted in the driver in this situation. That's why this broke to begin with. It's like a square peg in a round hole.
I looked into moving this fix more broadly into the server - but because this isn't actually the pattern we want to replicate it seemed fixing it only in this 1 place was most prudent. Once this error is moved into the driver it would obviate a need to ever need to do this in the server.
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.
Sounds good. Sounds like an easy fix that just needs to get done.
Gottchya. I had expected a test within the packages/server to be updated since that's where the change was made. |
I messaged @brian-mann to revisit. |
Is there another regression example or did markdown syntax use to render in the command log? |
…move extra backtick
@emilyrohrbough I'm not sure what you mean here - it appears this is failing in a different branch (?) |
@brian-mann yes a different branch off of develop - I was looking at the error message format & the markdown syntax in the terminal output. |
@emilyrohrbough I believe you're looking at our own custom formatted error for the snapshotting of mocha events - and this isn't representative of the way the system normally looks or behaves. From that error I can't really tell what is wrong or what should be expected to be there. If you could find a situation regarding a typical error case that's not using internal formatting / utilities I can take a look at it. From what I can tell though - I don't believe this is a regression anywhere. |
@brian-mann Ok! Sounds good to me. |
Added additional user changelog item + before/after pics of the 2nd regression |
…cypress-io/cypress into fix/cy-fixture-error-regression
16d98b8
User facing changelog
cy.fixture(...)
errorsAdditional details
Errors originating from the server (@packages/errors) were altered as part of a larger errors improvement here #20072. In this one particular code, ANSI color styles were showing up as a command log error.
How has the user experience changed?
Before
After
PR Tasks
cypress-documentation
?type definitions
?cypress.schema.json
?