Speaking generally, there are usually two processes involved in timeouts: process A making the calculations, and process B that is timing process A and seeing if it goes over a time limit. I think process B usually just has a timer, and then abruptly aborts process A. Process B doesn't usually try to talk to process A and get a progress report before it aborts process A.

So if this timeout works like normal timeouts, I don't think this ticket will be easy to code, and may not be possible at all.

Novem_Linguae, thank you for the explanation. I assume that there are statistics on how long regex searches take at different times of day and days of week. If so, these statistics should be made available to the users, and pages like [[:en:Help:Searching/Regex]] [https://en.wikipedia.org/wiki/Help:Searching/Regex] should have a link to this info, so users can schedule their "worst" regex searches for times when things usually go faster. Also, the timing process that shuts down the actual process could allow more time during periods when the server isn't as busy, and if users could see the chart, they would know when their chances were better.

It's bad practice to allow long-running processes in the main thread. Long-running processes should use the https://www.mediawiki.org/wiki/Manual:Job_queue. The engineering details of this could be to make some special pages such as Special:CreateBigSearch and Special:ListBigSearches, which would have much higher timeouts. You'd be able to navigate away from the search, and visit Special:ListBigSearches later to view the results.

Not sure if this will ever get coded up or approved. Complexity comes at a cost. But that'd be one way to do it.

Novem_Linguae, this is interesting. I can read the :MW:Manual:Job queue page, but I don't have the background to know what to do with it, as I am intimidated by scripts. I tried a different way, combining my regex search with regular searches with various words (case drive test meaning only would been) included or excluded. It took 17 combinations to exhaust all possibilities without timeout. The final total ended up at 2614, when the regex search alone tended to time out at about 400. I now know that this editing project will take about 7 times longer than I thought. The Special:CreateBigSearch approach would be helpful for a significant pool of editors who want regex results, don't need them immediately, and are intimidated by scripts. To get the total, we shouldn't have to repeatedly bifurcate the problem by asking, what if split it according to whether this word is in or out? And with Special:CreateBigSearch, the results would be all in one place instead of broken into artificial groups. I agree, it might never get coded up or approved, but it would be helpful.

It might also reduce pressure on the server if people didn't retry regex searches again and again, hoping that this time it will complete. To accomplish this, change the error message from "A warning has occurred while searching: The regex search timed out, so only partial results are available. Try simplifying your regular expression to get complete results." to "A warning has occurred while searching: The regex search timed out, so only partial results are available. You can use [[Special:CreateBigSearch]] to set up a search to run in the background, which can notify you to find the results when they are ready at [[Special:ListBigSearches]]."

In T406018#11231238, @Anomalocaris wrote:

The Special:CreateBigSearch approach would be helpful for a significant pool of editors who want regex results, don't need them immediate

To be clear though. that would be (relatively) a very small group of users, at the expense of a LOT of very expensive engineering (not just once, it needs to be kept working for ever and ever).