Prevent refresh fields error from breaking index patterns management page #11885
This PR removes a single line of code that is preventing the Discovery and Index Patterns Management page (and potentially others) from loading correctly. This is not affecting 100% of users as the execution path only occurs in a specific scenario.
The referenced issue was opened due to some users experiencing a problem where they were unable to delete a kibana index pattern if the respective ES index had been removed. I had a hard time reproducing the issue as the common code path worked fine, but thanks to a stack trace from @danielmotaleite, I realized it was in a certain code path that my setup wasn't calling.
The code path starts in route resolution if the page is requesting index patterns (through
Steps to Reproduce
The solution is a simple one line change - stop throwing the error back into the stack if the error indicates a missing ES index (which is represented by the IndexPatternMissingIndices error). The error itself is still surfaced in a
From here, the user can successfully remove the orphaned index pattern (which they were unable to do before).
Functionality and code LGTM.
I think this fix is an improvement over the current UX. However, I'm a bit concerned that we don't understand still why an index pattern might get into a bad state (either no fields at all or no searchable or aggregatable fields) in the first place. While this fix would improve the UX it could also potentially mask an underlying issue.
Now that we have figured out a fix and have it ready to go, I'd like to try and spend some more time trying to investigate why we might be getting into the bad index pattern state. I've asked a question on the issue; lets see if that gives us any clues. If we don't get anywhere for a few more days (arbitrarily saying 5), lets proceed with this PR.
There are two ways the index pattern can end up with no searchable/aggregatable info that I know of.
Basically anything that causes field_stats to fail after upgrading from 2.x to 5.x will put the index pattern in a bad state. Things should hopefully be better once we switch to the field_caps API.
referenced this pull request
May 18, 2017
I don't think we need to block this PR, or even keep the other issue. It sounds like there are two problems here, so if @chrisronline just opens a new issue about the 2.x to 5.x migration issues, pings the users who are active on 9224, we can move forward with this fix. At least then users won't get stuck, and we get this fix into the next release, pending a more inclusive fix. Thoughts?
#9571 is the closest I think. It's a symptom of not having any indexed data at least. I wouldn't say there's any migration issue to fix really. Field stats doesn't work without indexed data and there's nothing we can do about that beyond allowing the user to delete the index pattern if they don't plan on ever adding data. If they do add data after migrating the index pattern, they simply need to refresh their field list.
We don't seem to have any evidence indicating that there is an ongoing issue with migrated indices in