elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.78k stars 8.19k forks source link

The toaster error message which gets displayed in discover after user deletes a saved search is not clear. #9668

Closed bhavyarm closed 6 years ago

bhavyarm commented 7 years ago

Kibana version: master

Elasticsearch version: master

Server OS version: darwin

Browser version: chrome latest

Browser OS version: OS X

Original install method (e.g. download page, yum, from source, etc.): QA builds for tribe nodes

Description of the problem including expected versus actual behavior: The toaster message when a user navigates back to Discover after deleting a saved search under saved objects in Management is confusing. The toaster message in Discover gets displayed with unique search id(eg: 9684a9e0-cd3b-11e6-950e-3b217fa2ddeb)of that saved search.Also, I am not sure if Kibana should be displaying this message.

Please note in 5.1.1 this gets displayed with the saved search name instead of the id.

Steps to reproduce:

  1. Save a search in Discover
  2. Navigate to saved objects under management and delete it
  3. Navigate back to discover - toaster message gets displayed about not being able to locate that search - "Could not locate that search (id: 9684a9e0-cd3b-11e6-950e-3b217fa2ddeb)"

Errors in browser console (if relevant):

commons.bundle.js?v=14833:38 Error: Could not locate that search (id: 9684a9e0-cd3b-11e6-950e-3b217fa2ddeb) at SavedObject.applyESResp (kibana.bundle.js?v=14833:29) at processQueue (commons.bundle.js?v=14833:38) at commons.bundle.js?v=14833:38 at Scope.$eval (commons.bundle.js?v=14833:39) at Scope.$digest (commons.bundle.js?v=14833:39) at Scope.$apply (commons.bundle.js?v=14833:39) at done (commons.bundle.js?v=14833:37) at completeRequest (commons.bundle.js?v=14833:37) at XMLHttpRequest.xhr.onload (commons.bundle.js?v=14833:37)

Provide logs and/or server output (if relevant): None

toaster_console_error_message
stacey-gammon commented 7 years ago

I don't think there is much we can do about this. We can't grab the title to give a more informative error message, because the title doesn't exist anymore - all we have is the id.

We could detect a missing saved object, swallow the error, and redirect the user to the app's landing page, but I don't know if that would be better because then we are hiding information.

Bargs commented 7 years ago

It would be nice if we could figure out a way to prevent displaying an error in this specific scenario. The user did nothing wrong, we shouldn't be throwing an error in their face. But I don't think we should swallow all errors of this type. If someone visited an old bookmark for a saved search that was deleted a long time ago, this would be the correct behavior.

Perhaps a good compromise would be to display an info notification saying "Could not locate that search (id:). Showing default search instead." so it's more like a redirect than an error.

stacey-gammon commented 7 years ago

Removing discuss label, decided @Bargs suggestion of a blue info message instead of red warning label is a good resolution.

stacey-gammon commented 7 years ago

Initially I thought this would be as simple as changing a notify.error to notify.info call, but in actuality, a KbnError of type SavedObjectNotFound is being thrown. I don't think we currently have a way to catch known errors and map them to something other than type error.

nreese commented 6 years ago

Closed by https://github.com/elastic/kibana/pull/15508