Triaging as High, but i suspect if this is blocking SDoC it could perhaps be unbreak-now ?

If I understand this task correctly, this was fixed some time in the last year with a reworking of how CirrusSearch treats cross-namespace redirects. I currently get completions for MOS:, such as MOS:DUPECITE and more. Please reopen if this is not the case.

I can force the client to timeout, but I can't seem to reproduce the problem with displaying the response on screen. It seems plausible that display_errors was the problem, and is now fixed. I'm willing to call this complete and we can re-open if it is seen again.

That could potentially be related to display_errors. I'll see if I can hack something up in beta cluster to use a tiny timeout and reproduce the error

Could it be caused by display_errors being set to true in INI settings? (T211488)

Hm, yeah, it does seem to be checked correctly. So maybe quickUserCan does not work with whatever permission hook EventLogging handles?

ping @Tgr to clarify if we are thinking about ipblocks or rather status of users as autoconfirmed

Technically, this is a user-facing bug and a good first bug that someone could look at.

Some checking whether the user is allowed to create a page or not does happen, compare https://en.wikipedia.org/w/index.php?search=talk%3Adoes+not+exist&title=Special%3ASearch and https://en.wikipedia.org/w/index.php?search=does+not+exist&title=Special%3ASearch logged out. The latter is using the message searchmenu-new-nocreate.

Testing Structured Data on Commons on beta is blocked by this ... @Pchelolo is this something you're able to look at?

We'll take a look

The timeout problem was fixed by T216860 but I have no clue what cause the response from elastic to be displayed on site...

related: T216860

Soooo... I tried again and managed to reproduce it. The first obstacle I found is that somehow my first try was using HHVM (according to Logstash) despite PHP7 being enabled. So I disabled and re-enabled PHP7 and tried again. This time, the search succeeded but warned me that only partial results were available. Trying for the third time finally produced the error. I can also see that sort of JSON-encoded object being echoed. At a quick glance I cannot see any private info in there, but we'd better make it disappear...

In T216959#4979113, @Aklapper wrote:

Cannot reproduce the problem with the given URL. Instead I get an error message properly displayed:
Při hledání došlo k chybě: Kvůli dočasnému problému jsme nemohli provést požadované vyhledávání. Zkuste to znovu později.
(An error has occurred while searching: We could not complete your search due to a temporary problem. Please try again later. )

In T216959#4979113, @Aklapper wrote:

Cannot reproduce the problem with the given URL. Instead I get an error message properly displayed:

Cannot reproduce the problem with the given URL. Instead I get an error message properly displayed:
Při hledání došlo k chybě: Kvůli dočasnému problému jsme nemohli provést požadované vyhledávání. Zkuste to znovu později.
(An error has occurred while searching: We could not complete your search due to a temporary problem. Please try again later. )

As can be easily understood by "WMFTimeoutException", this happens upon reaching the timeout of 60 seconds. No idea about why info is printed on the screen though.

This is a feature request, not a bug. The Search Platform team currently doesn't have any front end folks helping us out right now, so even though this can be done, it won't be something we will take on.