-
Notifications
You must be signed in to change notification settings - Fork 2
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
SEARCH-8100 Make query timeout configurable #29
SEARCH-8100 Make query timeout configurable #29
Conversation
// If there's a configured timeout, ensure we don't let the query run longer than that | ||
if maxQueryDuration > 0 && elapsed >= maxQueryDuration { | ||
// TODO: cancel the query | ||
return backend.ErrDataResponse(backend.StatusBadRequest, fmt.Sprintf("Job %s still not finished after %v (status=%v)", jobId, maxQueryDuration, status)) |
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.
NOTE: The change to displaying maxQueryDuration
instead of elapsed
here just makes the error message cleaner. If the timeout is 42s, but we determine this at 43.020007 seconds, it was displaying all weird. This feels a bit more intuitive to show the configured timeout, a nice clean value.
...options, | ||
jsonData: { | ||
...options.jsonData, | ||
queryTimeoutSec: event.target.value?.length > 0 ? +event.target.value : undefined, |
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.
nit: do we need this event.target.value?.length > 0
check if validateQueryTimeout
already performs the check?
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.
oh wait ignore me, it's still valid if it's empty, nvm!!
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.
Yep, exactly!
* go get -u github.com/grafana/grafana-plugin-sdk-go * npx -y @grafana/create-plugin@latest update * SEARCH-8100 Make query timeout configurable (#29) * SEARCH-8103 Include info about scheduled queries in the timeout error (#30) * SEARCH-8309 Allow savedSearchId to be composed using variable(s) (#27) * SEARCH-8309 Allow savedSearchId to be composed using variable(s) * SEARCH-8309 Update QueryEditor to allow typing savedSearchId with ${variable} * SEARCH-8101 Cancel the query upon timeout (#31) * ran "npx -y @grafana/create-plugin@latest update" again * Bumps for v1.1.2
This moves away from the hardcoded 60-second timeout and enables the timeout to be configured on the dataset.
It can be left blank to mean no timeout, which can be useful if for some reason you really want long-running searches in your Grafana dashboard panels. But hey, you do you.
And users for whom 60 seconds was too restrictive can now tweak it to something more appropriate for their needs.
There's some basic validation in the UI, allowing only a positive integer value.
And just as before, you get an error message if the query takes longer than the configured timeout.
Future Work
We'll be following up soon with an enhancement that will cancel the query when the timeout kicks in (instead of leaving it running).