-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Notifications] Error Toasts display top-level error type and reason in addition to caused_by #81965
Conversation
The top-level error often contains more contextual information, and is included more often than the caused_by error; this leads to more information for the user.
@elasticmachine merge upstream |
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]page load bundle size
History
To update your PR or re-run it, just comment with: |
if (error.caused_by != null) { | ||
text += `${error.caused_by.type}\n`; | ||
text += `${error.caused_by.reason}\n`; |
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 see #70404 and #81857, and I'm starting to feel like this tries to solve a need specific to a single app, as opposite that something that all the toasts.addError
consumers may need. Am I assuming incorrectly here? If not, maybe using toasts.add
with a custom component as text
would be more suitable than adding specific logic in the 'generic' ErrorToast
component?
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 see now that the fields I'm proposing were displayed in the title
for #70404. We could do that, or us a custom component as you propose.
I'm happy to close this and implement an app-specific solution; if others need this functionality we can always reopen.
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.
Just to be clear: I'm fine with the implementation if this is something that is going to be widely used across multiple apps. I would just like to avoid app-specific code landing into core.
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.
@pgayvallet agreed! I'm happy to promote this to core when the need arises.
Closing as per #81965 (comment) |
Summary
Addresses #81857. In general, this additional info should provide more context to the user and not be redundant with the information in
caused_by
, but I'd appreciate if folks could help me try out some error cases, here.Example toast when previewing an invalid EQL query (via the EQL search strategy):
Where the
caused_by.reason
is in factnull
:Checklist
For maintainers