-
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
[Discover] Suppress "Missing index" toasts #149625
[Discover] Suppress "Missing index" toasts #149625
Conversation
Just tested in by deleting the e-commerce data while keeping the data view. Works as expected 🥳 |
Pinging @elastic/kibana-data-discovery (Team:DataDiscovery) |
cc @drewdaemon Maybe we could also hide the toast here to be consistent with Discover. I also like the error that is being displayed in Discover. Wdyt? |
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.
Unified search changes LGTM!
@stratoula totally. |
@stratoula @drewdaemon @stratoula
is changed to |
Created an issue here and I will add this to our 8.8 backlog #149836 |
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.
Overall the changes are very good - and very helpful! While you spotted some necessary changes for the data_views service, I have questions regarding a couple.
@@ -261,7 +265,10 @@ export interface DataViewsServicePublicMethods { | |||
* @params savedObject - Data view saved object | |||
* @params displayErrors - If set false, API consumer is responsible for displaying and handling errors. | |||
*/ | |||
savedObjectToSpec: (savedObject: SavedObject<DataViewAttributes>) => DataViewSpec; | |||
savedObjectToSpec: ( |
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'm not sure why this is needed as savedObjectToSpec
doesn't display toasts.
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.
@mattkime Right, I cleaned that up.
this.onNotification( | ||
{ title: err.message, color: 'danger', iconType: 'alert' }, | ||
`refreshFields:${dataView.getIndexPattern()}` | ||
if (displayErrors) { |
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'm confused about the work this change is doing. As best I can tell it swallows errors since the error is caught but not re-thrown which isn't desired.
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.
@mattkime The previous code was causing an unhandled promise error which was not allowing to switch from SQL to regular mode in UI (for a data view with missing index)
if (!displayErrors) {
return this.refreshFieldsFn(dataView);
}
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.
Can you handle the exception in the api consumer instead of changing the api?
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.
@mattkime Thanks for your suggestion! The thing is that the consumer is the data views service itself
await this.refreshFields(dataView, displayErrors); |
Would you suggest to add try-catch there depending on displayErrors
?
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.
No, at least in theory the error will propagate up to the api consumer's call.
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.
No, at least in theory the error will propagate up to the api consumer's call.
@mattkime dataView.get()
could still return a data view object for its consumer if we suppress exceptions for refreshField
. If we change as you suggest then the consumer code would not be able to proceed which conflicts with the purpose of this PR.
We can't both prevent unhandled errors AND pass errors to API consumers.
Agree with that. I'm not happy with the PR changes either. I can close it if that's our conclusion.
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.
Agree, there should be one way to handle it: to suppress the errors or to pass errors to the API consumers. This should also be clearly communicated to consumers, currently it seems it's a mixed handling of those cases?
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.
If we change as you suggest then the consumer code would not be able to proceed
@jughosta Perhaps we should set up some time to discuss this. There's something I'm not understanding here.
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.
Agree, there should be one way to handle it: to suppress the errors or to pass errors to the API consumers. This should also be clearly communicated to consumers, currently it seems it's a mixed handling of those cases?
I think our language might be conflating things. Currently, the api either displays errors or throws errors - and thrown errors need to be caught by api consumer code. 'Suppressing errors' could ambiguously mean either of those.
First we need to remove the possibility of errors from our communication regarding errors to successfully deal with errors. 🥲
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 created https://github.com/mattkime/kibana/pull/new/129020-inline-missing-index-error-mk to illustrate what I see as the path forward, particularly https://github.com/elastic/kibana/pull/150246/files#diff-eeffc98614da75c1f8e6ce9b07802c11dce0ae41f80b9540784f0f44c2e86133R307 - Now I think I did this before understanding what @jughosta was saying.
@jughosta - It took me a second reading to understand what you were looking to do -
[@mattkime] dataView.get() could still return a data view object for its consumer if we suppress exceptions for refreshField. If we change as you suggest then the consumer code would not be able to proceed which conflicts with the purpose of this PR.
Basically you're saying you want to be able to get a data view even if you can't get the field list. This isn't something thats currently supported by the API. A data view without a field list is of very limited use in most circumstances. Its an interesting idea. Current API consumers always assume the full field list is there - they don't have a notion of a data view with an unloaded field list. This is something I'd like to see changed but it would be a significant effort on the part of API consumers. Its actually something requested by solutions which deal with very large numbers of fields - that way they can choose when the field list is loaded.
{dataViewPattern ? ( | ||
<FormattedMessage | ||
id="discover.noResults.noDocumentsOrCheckIndicesAndPermissionsDescription" | ||
defaultMessage="Make sure the indices matching {dataViewPattern} exist, that you have permission to view them and that they contain documents." |
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.
My suggestion - although it should probably get 👀 from @gchaps - Make sure data view {dataViewName} with index pattern {dataViewPattern} has matching indices and documents and that you have permission to view them.
Does this work properly for text based languages?
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.
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.
My suggestion is to add the 2 words in bold:
Make sure that the data view {dataViewName} with index pattern {dataViewPattern} has matching indices and documents and that you have permission to view them.
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.
Also, can we update the error message:
Instead of
We encountered an error retrieving search results
how about
Unable to retrieve search results
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.
Thanks @gchaps !
@@ -218,7 +218,7 @@ export function useDiscoverState({ | |||
*/ | |||
const onChangeDataView = useCallback( | |||
async (id: string) => { | |||
const nextDataView = await dataViews.get(id); | |||
const nextDataView = await dataViews.get(id, false); |
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.
Anyplace where we're suppressing errors potentially needs a try/catch
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.
@mattkime Updated by wrapping with try/catch.
…r' into 129020-inline-missing-index-error
}); | ||
} catch (error) { | ||
// | ||
if (dataView?.isTimeBased() && dataView?.timeFieldName && query && mountedRef.current) { |
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.
dataView?.isTimeBased()
includes checking dataView?.timeFieldName
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.
@mattkime Thanks!
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.
One minor note, otherwise the code looks good and works well
…r' into 129020-inline-missing-index-error
…r' into 129020-inline-missing-index-error
…ng-index-error # Conflicts: # src/plugins/discover/public/application/main/hooks/use_discover_state.ts
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Async chunks
Page load bundle
Unknown metric groupsAPI count
ESLint disabled line counts
References to deprecated APIs
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: cc @jughosta |
Closes #129020