[Search] debounce error/warning toasts

[Dosant]

There was a general issue about spamming error/warning toast. We were hoping it will be solved in a generic way inside toast service, but the conclusion is that teams should handle this in their code.

We should prioritize handling this inside the search service because most of the feedback on this is coming from warnings generated by the search.

@lukeelmers: we are discussing potential enhancements to the toasts api (#67270) to give apps more tools to help with this, but for now, our recommendation is still for the data plugin to debounce these errors as that’s going to be the quickest solution (e.g. #62649). pretty much all of the complaints we have seen around noisy toasts are something that’s being initiated by the search service.
@Dosant: should we wait for toast api improvements
@lukeelmers: Could you still do some naive deduplication using toasts.get$()? i.e. get the current list of toasts, and only have search service create a new one if it has a unique error message?
This is logic you’d need in place anyway even if we did have an edit API, as you’ll need to know whether to edit or create a new one, so I think this could still be solved iteratively in absence of a new API

cc @sixstringcode @lukasolson

[lukeelmers]

@Dosant was this intentionally closed?

[Dosant]

@lukasolson, this issue was closed from Jira, I assume this is expected as not really needed anymore because we removed warnings altogether for now? #117252

[lukasolson]

Re-opening, as we have received feedback that even the "shards failed" messages can build up and prevent the user from being able to interact with Kibana.

[teresaalvarezsoler]

Re-opening, as we have received feedback that even the "shards failed" messages can build up and prevent the user from being able to interact with Kibana.

I confirm this is still the case, at least for version 7.16.

[ghudgins]

++ a customer brought this up unprompted in a roadmap presentation today.

[lukasolson]

Related: #106516

[ghudgins]

from a slack DM with a customer -

Since you seem sincerely interested, remind the [team working on this] that when the "SAVE" button is blocked by these messages I can't use ANYTHING ELSE in the entire system. This sounds like overstated hyperbole, but if I click the "hamburger menu" on the left, and navigate away, I LOSE ALL THE WORK THAT I CANNOT SAVE. So I truly am stuck. This simply isn't acceptable.

[sixstringcode]

Is there a need for a history view so we can make these toasts much less aggressive and point someone to the full list if they need it?

[mattkime]

I'm hoping to make an impact on this problem in 8.3. I see a couple different ways of approaching this -

1. Shard failure messages. These could likely be collapsed independent of the number of shards hit or the number of failures. This should be relatively easy.

2. Deduping messages with the same title and message. A bit more generic than the item above but still a simple case. Perhaps for most purposes this is the same item as above.

3. Some sort of close all button.

4. If you have more that 3 toasts then we display a single toast that provides a way to open a toast viewer. This covers the worst case scenario - a bunch of disparate apps are sending toasts without a way to dedupe them BUT the UI remains manageable.

---

For this release I'd like to focus on 1 & 2. It would be nice to come to a quick conclusion on this and get shit done.

[sixstringcode]

I am on board but want to understand a little more about the de-duping experience. My main concern is that it's obvious to me when I had many duplicate errors vs. a few errors of the same type. I am completely on board with improving the experience here, but want to make sure that will still give enough context that a user knows when there are a few errors vs. an avalanche we deduped.

[mattkime]

We should probably have a list of the error types since user response will vary based on the specific error.

• Shard failure messages - I think one is enough, as user action wouldn't change based on multiple errors.
• Failure to load data view - same
• Request timeout - same
• Search session errors - Have these been a problem?
• Script errors - I need to see how these are display. This is a case where one failure vs many may mean different actions would be taken by the user

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[thomasneirynck]

Would recent improvements to toast-storms already improve on this? (e.g. #149488)

Might help to add some clarity what exactly been addressed and what is still open.

[davismcphee]

@thomasneirynck #149488 improves this to some extent, but only in the context of Discover, we didn't make any changes to the search service. We've also made a couple of other improvements that are unrelated to the search service but which improve this issue in certain circumstances:

• Remove No matching indices found toasts
• Throttle KbnUrlStateStorage error messages
• Throttle toast storms related to saving/restoring URL state

[kertal]

Adding one issue to improve shard error warnings in Discover / Saved searches on a Dashboard
#155216
Such warnings are debounced in the search service, however having x saved searches with different shard errors causes , x toasts. this will be resolved with #155216. Don't know if it's worth to keep the issue open after that.

[kertal]

@thomasneirynck you're fine with closing this? The remaining related work is tracked in this issues:

• [Discover] Inline shard error warnings #155216
• [Discover] Inline toast error messages in surrounding documents #150154

[thomasneirynck]

wrt #116686 (comment)

+1 on closing, thx @kertal !