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

[Controls] Add Fatal Error Handling #133579

Merged
merged 13 commits into from Jun 15, 2022

Conversation

ThomThomson
Copy link
Contributor

Fixes #129906

Summary

Adds simple fatal error handling to the control wrappers, which is similar to how the embeddable frame handles it.

This PR also changes the Options List and Range Sliders to catch and throw errors properly when their data views are missing.

Screen Shot 2022-06-03 at 5 59 12 PM

@ThomThomson ThomThomson added Feature:Dashboard Dashboard related features Feature:Input Control Input controls visualization Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas loe:medium Medium Level of Effort impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. Project:Controls v8.3.0 v8.4.0 labels Jun 3, 2022
@ThomThomson ThomThomson marked this pull request as ready for review June 6, 2022 13:44
@ThomThomson ThomThomson requested review from a team as code owners June 6, 2022 13:44
@ThomThomson
Copy link
Contributor Author

@elasticmachine merge upstream

@botelastic botelastic bot added the Feature:Embedding Embedding content via iFrame label Jun 6, 2022
@ThomThomson
Copy link
Contributor Author

@andreadelrio, this may need a styling once-over. I've added a new compressed layout to the ErrorEmbeddable class which isn't the best looking thing at the moment!

Copy link
Contributor

@Heenawter Heenawter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested locally + code review - everything works great from a behaviour perspective! Tested both deleting just the data view and deleting the entire index.

This is more of a question for @andreadelrio I think, but the error embeddable doesn't display nicely on small or medium sized controls where "Expand width" is set to false - it only shows properly on large controls:

image

Perhaps we could display a shortened version of the error in these cases, with the full error being displayed via popover or something? Or, at the very least, I think that we should ensure that the alert icon is always visible, since the above small and medium views only show part of data view ID, which doesn't really make it clear that an error occurred.

const node = this.compact ? (
<EuiFlexGroup
style={{ height: '100%', whiteSpace: 'nowrap' }}
gutterSize="none"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps gutterSize="xs" might be a little better here?

image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Heenawter, you really caught how little attention I put into the design of this hahah!

I decided to cut my time fiddling with CSS short, but I'm hoping that @andreadelrio can take a look and fix some things I wasn't able to get to:

  1. I couldn't change the error background color to white - for some reason the background-color rule is disabled, but only in error cases.
  2. Using any gutter size shifts the EuiFlexGroup content upwards, because it adds a negative margin. You can see this even in the XS size in the screenshot above, it isn't exactly centered anymore. Is there something that the flex group needs to be wrapped in to avoid this?
  3. I attempted to wrap the error text Markdown in a box that would use text-overflow:elipsis, but it didn't apply at all. I'm wondering if the markdown component comes with its own styling that overrides that.

Overall, this is a weird case, because the actual error text includes a link which needs to be rendered as markdown. I honestly wonder if we could just have a generic a fatal error has occured message on the control itself with a tooltip that shows the full message... Even then, the hyperlink wouldn't be created so the error message would look pretty bad, including all the markdown code in a popover hah.

@andreadelrio
Copy link
Contributor

  • @ThomThomson Curious, why is editing the control disabled when this error occurs?

image

  • Should we align the wording with the error in panels? locate vs find, for example.

  • I think since space is so limited we need to shorten this as much as possible. Can we say Re-create it instead of click here to re-create it?

  • Following up on the comments regarding a tooltip/popover. I think given that the error is not really useful in small and medium sizes we could shorten the text and move the details to a popover. @ThomThomson is that possible?

image

@ThomThomson
Copy link
Contributor Author

@andreadelrio, I've disabled editing when the control is in a fatal error state, because these are technically un-recoverable errors, which replace the Control with an ErrorEmbeddable. Plenty of other embeddables work this way when they get into an error state, but embeddables like Lens have their own specialized error handling which allows them to recover.

The wording here actually can't be modified without changing it everywhere, because this is unfortunately the actual error text that the data views service throws when it is unable to locate a data view. The way the Embeddable panel, and the control frame after this change, handle fatal errors is by exposing the actual error message. This helps with DX, but is sometimes not great from a UI perspective.

I was thinking of a tooltip, but if we used a popover, we could actually potentially render the markdown correctly on the inside of the popover, that's a good idea as long as you think the UX is okay.

So maybe the condensed error would show like this:
Screen Shot 2022-06-06 at 2 59 38 PM

And on click we render markdown inside a popover

@andreadelrio
Copy link
Contributor

@andreadelrio, I've disabled editing when the control is in a fatal error state, because these are technically un-recoverable errors, which replace the Control with an ErrorEmbeddable. Plenty of other embeddables work this way when they get into an error state, but embeddables like Lens have their own specialized error handling which allows them to recover.

The wording here actually can't be modified without changing it everywhere, because this is unfortunately the actual error text that the data views service throws when it is unable to locate a data view. The way the Embeddable panel, and the control frame after this change, handle fatal errors is by exposing the actual error message. This helps with DX, but is sometimes not great from a UI perspective.

I see! thanks for all the context.

I was thinking of a tooltip, but if we used a popover, we could actually potentially render the markdown correctly on the inside of the popover, that's a good idea as long as you think the UX is okay.

So maybe the condensed error would show like this: Screen Shot 2022-06-06 at 2 59 38 PM

And on click we render markdown inside a popover

I like this! The reason I was suggesting a popover instead of a tooltip is to allow for the inclusion of a click action (which is not possible when using a tooltip). I think a simple popover (no footer, no title) would work here. If possible, I would like for us to add "Learn more" at the end of the error text. We can show it only for non-small/medium controls if that works better. Just to account for the possibility that users might not know this error text is clickable and to let them know we're trying to provide them more info so they can recover from the error.

@andreadelrio
Copy link
Contributor

Also, @Heenawter you're developing what we call an eagle eye for design. Very useful to have!

@ThomThomson
Copy link
Contributor Author

I've quickly re-designed the compact error embeddable to hide the error message in a popover. It still needs some design work, but this makes it a lot easier to control how the error control looks.

Screen Shot 2022-06-07 at 4 58 42 PM

@cchaos
Copy link
Contributor

cchaos commented Jun 8, 2022

I'd ask that you get the @elastic/ux-writers involved on this PR. At quick glance "Fatal" seems like extremely dangerous language. As a quick option I would just put "Can't find data view" as the main input text.

@ThomThomson
Copy link
Contributor Author

That is true - Fatal is a pretty extreme word to use.

We can't use the actual error text as the main input text because the error could be anything and it could include any amount of markdown, which would potentially make it too large for this small space - hence the popover.

Maybe we just say An error has occurred. Short and sweet.

@KOTungseth, I'm open to any suggestion!

@kellyemurphy
Copy link
Contributor

Hi @ThomThomson, Learn more links typically go to the documentation not a popover, this is a new UI pattern to use it that way. If I'm understanding correctly, the issue is that there is limited space and a multitude of reasons this could error out. The popover in the latest image is repeating the information in the box below, so maybe we don't need to show it in both places.

Just a general note about error messages, the most important things are to A. let them know what went wrong and B. tell them what they can do about it. So what do we want them to do with a generic error? Try again? Contact support?

@ThomThomson
Copy link
Contributor Author

@kellyemurphy, that latest image is a little confusing - it's actually a dashboard, with 2 Controls and one Panel. All three of these things are in an error state, so that is the cause of the repetition.

I'm absolutely open to wording suggestions here. Basically we need one generic error message that fits in a small space and would prompt the user to click on it in order to see the actual error text.

It would be the actual error text inside the popover which would let them know what went wrong, and also tell them how to fix it.

@ThomThomson
Copy link
Contributor Author

Here is a clearer picture of what one of these error controls looks like after the design PR by @andreadelrio. Hopefully that makes this a little clearer. The generic part is at the top, and the part that gives the real error and instructions on how to fix it is in the popover at the bottom.

Screen Shot 2022-06-08 at 6 06 00 PM

@kellyemurphy
Copy link
Contributor

Ok, so where does the Learn more link go? If clicking that opens the popoever, we need different words.

For phrasing, I'd recommend:

An error has occurred. Expand

or

There is an error. Read more

And then inside, it would say Couldn't locate the data view (ID: xxxxx), you need to <LINK>recreate</LINK> it.

@ThomThomson
Copy link
Contributor Author

ThomThomson commented Jun 8, 2022

The Learn more link is actually the same as the other text in that it just opens the popover. I like An error has occurred. Read more that sounds much better than what we had. Thank you for the help!

@gchaps
Copy link
Contributor

gchaps commented Jun 8, 2022

Maybe we can shorten it a bit:

Can't locate the data view (ID: xxxxx). <LINK>Recreate it</LINK>.

@ThomThomson
Copy link
Contributor Author

@gchaps, the text there is actually coming from the error message itself, we could definitely change it to be shorter, but that is outside of the scope of this PR.

@ThomThomson
Copy link
Contributor Author

@elasticmachine merge upstream

Copy link
Contributor

@andreadelrio andreadelrio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for making all those updates. Design LGTM.

error: Error | string,
input: EmbeddableInput,
parent?: IContainer,
private compact: boolean = false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we have a unit test (snapshot) to cover the new param?

@ThomThomson
Copy link
Contributor Author

@elasticmachine merge upstream

Copy link
Member

@tsullivan tsullivan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
embeddable 75 80 +5

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
embeddable 397 398 +1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
controls 426.5KB 427.4KB +874.0B

Canvas Sharable Runtime

The Canvas "shareable runtime" is an bundle produced to enable running Canvas workpads outside of Kibana. This bundle is included in third-party webpages that embed canvas and therefor should be as slim as possible.

id before after diff
module count 4956 4958 +2
total size 7.7MB 7.7MB +3.3KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
embeddable 66.3KB 67.7KB +1.5KB
Unknown metric groups

API count

id before after diff
embeddable 487 488 +1

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@ThomThomson ThomThomson merged commit 7757dbc into elastic:main Jun 15, 2022
ThomThomson added a commit to ThomThomson/kibana that referenced this pull request Jun 15, 2022
* Add fatal error handling to Controls
Co-authored-by: andreadelrio <andrea.delrio@elastic.co>

(cherry picked from commit 7757dbc)
ThomThomson added a commit that referenced this pull request Jun 15, 2022
* [Controls] Add Fatal Error Handling (#133579)

* Add fatal error handling to Controls
Co-authored-by: andreadelrio <andrea.delrio@elastic.co>

(cherry picked from commit 7757dbc)

* manually updated snapshot
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Dashboard Dashboard related features Feature:Embedding Embedding content via iFrame Feature:Input Control Input controls visualization impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:medium Medium Level of Effort Project:Controls release_note:fix Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas v8.3.0 v8.4.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Controls are not handling the deletion of dataviews correctly for data view without time series panels.
9 participants