Most of the time, I expect a query to run in less than a second. If it takes longer than that, I assume that I’ve accidentally made an expensive query. In that case, a) I need to make it less expensive (e. g. a LIMIT clause), and b) I don’t actually need WDQS to run the query until it hits the time limit. And that’s always a crappy feeling when I realize that WDQS is now going to unnecessarily labor for 30 seconds (full load, presumably). Adding a button to cancel / abort a running query would take load off the service and allow the user to run the improved query earlier.
- Mentioned In
- T175448: Provide mechanism(s) to avoid WDQS timeouts for certain pre-approved queries
T170279: Query editor toolbar
rWDQG20d538864a46: Add ability to cancel queries
rWDQGf40c95831ba5: Add ability to cancel queries
rWDQG8bceea85096a: Add ability to cancel queries
T147114: "Run" button not re-enabled after some queries fail
I wanted to ask for pretty much the same thing. :) I often make stupid mistakes that mean my query will either time out or return far too many results. It used to be possible to just click "Run" again, but now that button gets disabled until it returns results or times out, so once I've fixed the mistake, there's a long delay before I can run my new query.
I'm not really bothered about specifically having a button to stop a query, but I would really like to be able to start the new query without a long delay. For me, it would be ideal if the "Run" button were re-enabled when the query changes (and if the user runs the new query before the old one finishes/times out, silently cancel the old query).
@Smalyshev: Good to know. So the client would send the cancel request while the query GET request is still pending, and that would then return… 204 No Content? 408 Request Timeout? (I suppose it doesn’t matter – the client knows it canceled the query, it doesn’t need to check the response to detect that.)
@Nikki: One workaround is to open a new query tab ;) Ctrl+L,C,T,V, Enter.
Do we know that such queries have a big performance hit or cause undue strain on the servers? I agree that in an ideal world this feature would be useful, but if these queries are not causing any significant issues then practically speaking it may not be worth investing engineering time in such a feature.
Another note: cancel requires POST support as it seems, which currently is not supported. Also, since we have more than one server, we need some kind of affinity on Varnish side, which I am not sure whether we have or not.
@Deskana one query is probably no big deal. Lots of heavy queries can be a problem. But those are usually not from GUI but from bots.
I usually end up right clicking the tab and duplicating it, that way I don't lose what I currently have on the clipboard. :) I suppose refreshing the page would work too but I never trust browsers/pages to not lose something if I do that.
Also, I didn't mention why what I suggested would be ideal (for me): Most of the options (deciding to sit and wait (and succeeding in doing that without getting distracted by something else ;)), clicking a stop button, refreshing or opening a new tab) need some kind of deliberate action from me, which interrupts what I'm doing. What I suggested would be unobtrusive - I could just continue editing and running the query until I get the results I want without it interrupting me.
When I hit that problem I just press F5 to reload the page, because the query in the editor is still preserved.
I am not sure if canceling the query is worth the effort at the moment, because of the strict Blazegraph execution limit.
In the future when that limit will be greater we might want to think about canceling queries.
If this ticket includes cancelling the query on the server, should we make a new ticket for simply being able to run a new query before the existing one has timed out? It used to be possible before the run button started being disabled, so it seems like making that possible again would be easy to do even if we can't actually cancel the query on the server yet. It would be nice if it could cancel the existing query when starting a new query, but I don't think it really makes a difference to the user.
My concern here is that it will encourage very bad pattern of behavior - running a bad query, seeing it takes long, abandoning it, tweaking, running it again, etc. so that at the end the server ends up with 20 heavy queries running. Yes, I know you could just open a new window or reload, but this is higher barrier to producing lots of heavy queries than just clicking a button.
Actually even if we don't know which server the query went (there really should be some indication), we can send the cancellation to all servers. Though this will not scale once we have hundreds of query server.
(About task status: If this should be fixed upstream, add Upstream to this task)