-
Notifications
You must be signed in to change notification settings - Fork 9.6k
core: add DevtoolsLogError and TraceError artifacts
#15311
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
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
- Loading branch information
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -367,6 +367,8 @@ class Runner { | |
|
|
||
| let auditResult; | ||
| try { | ||
| if (artifacts.PageLoadError) throw artifacts.PageLoadError; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Looking at the smoke test as examples, maybe this should throw a simple new LH error rather than repeating the page load error a million times? The metric section in particular could end up pretty gnarly with the longer network errors. The top-level pageLoadError would be the main explanation, the individual audit errors can simply say they were unable to run due to a page load error or whatever?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not an outrageous idea, although I think repeating the same error message everywhere has benefits. I've responded to a few bugs where users ask about the "traces gatherer did not run" error message but completely miss the more detailed top level run warning that explains the problem better. I believe users (myself included sometimes) skip over the warning section and go straight to the giant wall of red text for the failure information. If we have a generic "Page load failed error" I think we're missing an opportunity to explain the error in the first place the user's attention in drawn to.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The message could be "An error during page load prevented this audit from running. See the error message given at the top of the report" or something.
How long are we talking here? 10x/100x than what I just wrote above?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yeah but from a JSON consumer perspective this makes less sense.
It vary depending on what error details are provided. FWIW the error will be in a tooltip most of the time. If we're really worried about blowing up the metric section though, I would prefer to elide the displayed text rather than choose a more indirect albeit shorter error message. |
||
|
|
||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm unsure about this change. My understanding from discussing this earlier was that the most non-breaking / simple change here would be for L380 conditional to include
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
That's what this behavior is. We throw an error early if we can't trust the DT log or trace (i.e. there was a page load error). If we added The situation is definitely confusing in both situations, so I won't die on this hill. We could also consider one of the alternatives.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Ah, my actual working suggestion would have to be adding to L376/377, then. Does throwing the artifact PageLoadError here have desired results? as in, now instead of throwing a Also, when would this actually occur - do we not throw on a page load error earlier than this function?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yeah https://googlechrome.github.io/lighthouse/viewer/?gist=765026ff99e2f51e1e5b82675e26ef46
We will always surface the page load error before mentioning any missing artifacts now. We still might have a missing artifact error if we did We don't throw on a page load error but it is listed as a top level warning.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes, see the discussion at #8865 (comment) linked from #9236
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My only concern here is the code we would run in Can we instead pull this up into where
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This could be a good idea, the sentry logging is completely unnecessary, but FWIW this is unchanged from current behavior, it's just using the PageLoadError instead of a
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed it's same behavior as today - let's do in a second PR since this one is big enough already.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Second PR sounds good |
||
| // Return an early error if an artifact required for the audit is missing or an error. | ||
| for (const artifactName of audit.meta.requiredArtifacts) { | ||
| const noArtifact = artifacts[artifactName] === undefined; | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.