-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Lens] Faster field existence failures by adding timeouts #97188
[Lens] Faster field existence failures by adding timeouts #97188
Conversation
Pinging @elastic/kibana-app (Team:KibanaApp) |
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.
Tested and still works fine, LGTM.
Two notes:
- Should we extend the error message shown in the UI with the ES error message (or maybe hide it if it's because of a timeout)? Some users will always see this warning triangle because their cluster is slow. We did something similar for the input control vis and it caused quite some user confusion (Input controls: Improve behavior on terms list timeout #73253)
- 500ms to 5s seems like a pretty big difference - could you explain how you arrived at these values? I'm no expert, but I would have expected the shard timeout to be much higher.
@flash1293 I will look at options to show a better explanation/icon for timeouts vs other types of failures. Maybe a clock icon instead of a warning triangle would be appropriate. I can clarify this using a comment in the issue, but you're right that we could move the timeouts closer together, for example we could do 4s and 5s. One of the interesting things about a super-short timeout is that each shard will return partial results if it's found any in the time, which is kind of similar to the sampling ideas we've talked about. But if ES is bottlenecked for some reason it's probably best to have a slower timeout. |
@flash1293 please take another look as I've hooked up a new key in the state. I tested locally by setting the timeout super low. |
@elasticmachine merge upstream |
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 love this way of indicating timeouts - it's clear what's happening and users will know what to expect.
Just one thing I would like to change - as soon as you run into the timeout, field information popovers also won't be populated. This doesn't seem necessary, IMHO we should still try to run these requests even if the existence query timed out.
💚 Build SucceededMetrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: |
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
…97551) * [Lens] Faster field existence failures by adding timeouts * Increase shard timeout and add timeout-specific warning * Fix types * Fix import * Hide field info when in error state, but not timeout Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Wylie Conlon <william.conlon@elastic.co>
We've decided that if the field existence query takes too long, we want to fail and show all fields. I've been unable to find large improvements to the performance, but there are some small improvements to the failure case added here.
One case that is hard to work with is many shards: there is a per-shard timeout and a global timeout, so I've set the per-shard timeout very low and the per-shard timeout higher.
This adds a new timeout warning to the field list:
Closes #92493