-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Improve frontend error messages written to system log #17616
Conversation
protected hassConnected() { | ||
super.hassConnected(); |
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 think the reason we did this in core, was that we would catch error as soon and as low as possible, I see that that makes no sense because there is no connection yet, so they can not be send to core anyway, but I think the idea was that we would store those errors and send them as soon as there would be a connection, or if the error would be in the connection itself show it on screen.
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.
Yeah I thought about that as well, but I think the logging listeners should stay separate rather than complicating them with startup logic. I think a follow up enhancement would be to add startup listeners early on, and then remove them here after the connection is complete.
Just storing them and expecting to log later is flawed since many such errors would likely prevent the connection from completing or even defining the custom element. It's also not necessarily straightforward to handle. For example, I tried to also test errors inside other mixins, but those didn't even get logged to the console let alone handled by the listeners.
Nice! |
@frenck consider adding this to release notes for 2023.9. Because of the additional logging of promise rejections, users might see new errors in the log that aren't actually new, but should still be reported. |
Proposed change
This overhauls messages sent to the system log for frontend errors, hopefully making them much more useful, complete, and less confusing to users.
error
events are not fired in async code, so we're currently not covering all bases)Error
instancesSample Output from Multiple Browsers
Type of change
Example configuration
Additional information
Checklist
If user exposed functionality or configuration variables are added/changed: