Cluebot NG has a lot of edits (~3.5 million) and almost all of them will be in main space. Also, running this exact query on other users works fine, although it does take a long time. Is this just a timeout because the query is taking so long for users with high edit counts?

This query is checking namespace 6

In T108782#1530606, @Nakon wrote:

This query is checking namespace 6

Indeed, and that's kind of my point. If the query trying to find the fifty most recent edits in that namespace belonging to that user, then it may essentially have to check every edit, in order, to see if it's in that namespace. That normally wouldn't be a massive problem, but MediaWiki wasn't really designed under the assumption that one user might get 3.5 million edits!

Removed my previous comment as it was incorrect. I would expect, however, that mediawiki gracefully reject the request rather than die with a db error

MariaDB [enwiki_p]> select count(*) from revision_userindex left join page on page_id = rev_page where page_namespace = 6 and rev_user_text = 'ClueBot NG';
+----------+

+----------+
1 row in set (5 min 59.50 sec)

Given the sheer scope of the database query I am not sure that its possible to be effective on WMF wikis.

In T108782#1530672, @Nakon wrote:

Removed my previous comment as it was incorrect. I would expect, however, that mediawiki gracefully reject the request rather than die with a db error

I would agree that it should, but often it's hard to know that something's going to take a long time before you run it. One can apply some kind of heuristic such as "if the user has over ARBITRARY_NUMBER_OF_EDITS then don't run the query". Something like this could be added here.

https://commons.wikimedia.org/w/index.php?title=Special:Contributions&offset=20160429033856&contribs=user&target=Jarekt&namespace=828&tagfilter= will give the same error:

A database query error has occurred. This may indicate a bug in the software.

Function: IndexPager::buildQueryInfo (contributions page filtered for namespace or RevisionDeleted edits)
Error: 2013 Lost connection to MySQL server during query (10.64.16.8)

@Multichill I think in your case it was a 1 in a million error, I cannot reproduce (it can also happen if database is cold for contributions on a user- reloading the page will solve it).

The general issue is that there is literally (this is exact, we counted them) 2 million different queries that can be done for recentchanges (that doesn't mean 2 million different users or namespaces, those are not counted here, it means 2 million different parameters/options/checkboxes that can be combined to create a query). We optimize with indexes for the most usual ones, but it is very difficult to optimize in absolutely all cases/combinations- specially for edge cases where a user has many edits.

I think the current state, while not optimal, is better than trying to limit the query options. I think Deskana suggestion is ok, maybe capture the error and try to be more informative. New optimizations are applied constantly, but I hope this clarifies why this is not easy to fix.