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).

Looks like there is a way to do it: https://wiki.blazegraph.com/wiki/index.php/REST_API#queryId

@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.

I usually introduce some error in query and then press Run :)

Change 316042 had a related patch set uploaded (by Smalyshev):
Add URL to cancel running query

https://gerrit.wikimedia.org/r/316042

Change 316044 had a related patch set uploaded (by Smalyshev):
Add ability to cancel queries

https://gerrit.wikimedia.org/r/316044

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.

@WikidataFacts: Does this task requires upstream fix?

@Gehel very true. That said, it won't hurt performances either and what about all the other problems of not being able to stop a query? (I hate when I have to restart my browser and/or computer who froze just because I dumbly forgot to remove a wdt:P279*)

This does not address the issue raised in {T136479#2338442} - I'm going to file a new task for it.

Change 316044 abandoned by DCausse:
[wikidata/query/gui@master] Add ability to cancel queries

Reason:
no longer in progress, please reopen if not true

https://gerrit.wikimedia.org/r/316044

Idk this looks like it would require an intermediate database to keep track of which query ids are being sent to which servers.

In T136479#8722821, @Lectrician1 wrote:

Reopening because it was declined for a reason unrelated to the original request. Users want to be able to cancel queries so that they can create new ones easily and not have to wait - not because this will increase performance (and what ideas do you have?).

This is T245643: Stop current query from running on Query Service.

Yeah @Aklapper this task is requesting for the ability for users to cancel a query on the query server, not starting another query when another one is running. This task should be open.

I mean it's totally possible. You just set up a tracking database to determine which requests are sent to each server. Isn't this up to WMDE to decline?

It’s up to WMF to decline, as they are responsible for the query service backend, and WMF have already declined it, see T136479#5897103.

What does that comment even mean?