-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Reporting] Update chromium exit behaviour #113544
[Reporting] Update chromium exit behaviour #113544
Conversation
Pinging @elastic/kibana-reporting-services (Team:Reporting Services) |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
map((err) => { | ||
logger.error( | ||
i18n.translate('xpack.reporting.browsers.chromium.pageErrorDetected', { | ||
defaultMessage: `Reporting encountered an error on the page: {err}`, |
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.
Should this log line be warning
since the error is ignored? And/or should the content mention that we are ignoring the error?
Catching and logging the error makes this similar to the pageRequestFailed$
observable.
I am in favor of updating the content on line 228 to remove the This error will be ignored
text. That has confused users in times when the report eventually does fail. But I do think this log level should be warning
since we're not throw
ing the error after logging it.
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 left a comment about making the tone of the message similar to line 228
@elasticmachine merge upstream |
…cit that the error will be ignored
Thanks for the review @tsullivan , I think I've addressed your feedback. Would mind taking another look? |
@elasticmachine merge upstream |
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.
LGTM
@elasticmachine merge upstream |
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: |
* move uncaught exception out of exit$ * reintroduce original error, but as a log instead * change log level: error -> warning. also update copy to make it explicit that the error will be ignored Co-authored-by: Kibana Machine <[email protected]>
* move uncaught exception out of exit$ * reintroduce original error, but as a log instead * change log level: error -> warning. also update copy to make it explicit that the error will be ignored Co-authored-by: Kibana Machine <[email protected]>
* move uncaught exception out of exit$ * reintroduce original error, but as a log instead * change log level: error -> warning. also update copy to make it explicit that the error will be ignored Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Kibana Machine <[email protected]>
* move uncaught exception out of exit$ * reintroduce original error, but as a log instead * change log level: error -> warning. also update copy to make it explicit that the error will be ignored Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Kibana Machine <[email protected]>
Summary
The following issues report poor UX associated with reporting crashing on unhandled page exceptions:
The result is that users are not empowered to dig deeper into resolving the issue (in both cases it is a bad URL, one has a bad ID reference and one contains outdated, incompatible state for dashboard).
The changes proposed here update the chromium's page exit behaviour to not close when an uncaught exceptions occurs on the page. Specifically, we don't close the browser on the pageerror event. This is one step closer to improving errors for reporting.
The effect of this change is that for URLs visited during the report generation process, we will still generate a screenshot and render any warnings that may occur.
Case: URLs with out-of-date state
With throwing behaviour (current)
Screenshots
Logging exception, but not exiting (proposed changes)
Screenshots
Sample error log
Checklist
In this case, if we did not throw on the page error we have a better chance of guiding the user back to dashboard, where the actual problem is that needs to be addressed.
How to test
Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.
When forming the risk matrix, consider some of the following examples and how they may potentially impact the change: