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

Way to surface non-critical errors in the report #1512

Closed
ebidel opened this issue Jan 23, 2017 · 5 comments
Closed

Way to surface non-critical errors in the report #1512

ebidel opened this issue Jan 23, 2017 · 5 comments

Comments

@ebidel
Copy link
Contributor

ebidel commented Jan 23, 2017

From #1492 (review)

For individual gatherers/audit errors, we surface debugString.

Right now, fatal errors stop the extension from running and we show a "report error" button. However, for non-fatal errors that happen outside of the gatherer -> audit -> report pipeline, we don't have a way to surface those errors to extension users.

Without analytics, we don't know about non-fatal errors. The HTML report could have a section where users see overall LH non-fatal errors and file bugs against us.

@brendankenny
Copy link
Member

It seems this could be broken down into

  • a general system for logging or capturing errors in Lighthouse
  • having those errors available for output in some way: surfacing in the report, error reporting if that's enabled, etc

@brendankenny
Copy link
Member

after #1591, we probably want to add the errors in the gatherer -> audit -> report pipeline to this as well. Some things might not make sense, but e.g. if we couldn't find FCP and didn't calculate a bunch of perf metrics it should probably be called out at the top as well (this was the spirit of @addyosmani's original #812)

We may want a better icon to mark them in the report as well :)

@brendankenny
Copy link
Member

one more thought for the CLI: as @patrickhulce notes in #1605 (comment), if something gets logged at the beginning of the LH run, it probably won't get noticed. If we figure out a nice way to pipe errors to the report (or whatever), we could also drop them in the log at the end of the CLI run so they're very visible there too.

@brendankenny
Copy link
Member

brendankenny commented Sep 28, 2017

Starting list of things to warn on:

@patrickhulce
Copy link
Collaborator

addressed by #3692

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants