I tried changing search query to a different NS name, got the same red links and NS name doubling with "template" instead of "Wikipedia". https://en.wikipedia.org/w/index.php?search=intitle%3A%22template%22&title=Special:Search&profile=advanced&fulltext=1&ns0=1

I have reproduced this on mediawiki.org too: https://www.mediawiki.org/w/index.php?go=Go&search=intitle%3A%22Manual%22&title=Special%3ASearch&ns0=1&ns12=1&ns100=1&ns102=1&ns104=1&ns106=1

Thanks for reporting this, this has been sitting on my list for a while. https://species.wikimedia.org/w/index.php?go=Go&search=intitle%3Atemplate&title=Special:Search&ns0=1 was my case in case anybody needs another example.

There are a few things going on here:

Redirects that shouldn't be indexed are being indexed

When building documents we have the following limitation on when redirects are indexed:

$redirect->getNamespace() === NS_MAIN || $redirect->getNamespace() === $title->getNamespace()

This does not look to be respected by in-place mutation of the redirect arrays when a new redirect is created

Redirects are not being cleared out on rebuild

Not sure why yet, but edits to the page that should be replacing the full document (including the redirects array) are not replacing it. Suspect we have something wrong with the noop handler parameters but more investigation is needed. Reminds me a bit of a long-standing concern with the noop handler that it should ideally either be nooping the whole document or none of it, but what it actually does is a per-field noop.

Mixup of title and prefixed title

When the redirects from another namespace are indexed they should not have the namespace prefix. But clearly this is happening here. That shouldn't be a problem for the main namespace since we are not supposed to index redirects from other namespaces, but redirects within non-main namespaces need to be investigated and validated for correctness here.

ebernhardson opened https://gitlab.wikimedia.org/repos/search-platform/cirrus-streaming-updater/-/merge_requests/157

Correctly update redirects of existing pages

Attached patch is a partial fix, it addresses indexing redirects that shouldn't be indexed and the mixup of title and prefixed title. I'm still looking into why the redirects are not being correctly updated on document rebuild.

MR has been updated to also handle the problem where redirects were not correctly updated during a rebuild. Once that is deployed fixing the index will be two steps:

1. We can use a regex query against redirect.title to find all pages with a : in the redirect array and issue a rerender. This should cover most of the bad data in the index
2. The problem with the redirect array not always being updated is a little harder to fix directly. The in-place mutation should have covered most of it but clearly that doesn't work 100% of the tim. We will depend on the Saneitizer process which rerenders all pages over a 16 week period. Those pages will also update from normal edits (including null-edits).

Change #1064482 had a related patch set uploaded (by Ebernhardson; author: Ebernhardson):

[mediawiki/extensions/CirrusSearch@master] Add support for natural title sorts

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

Ignore above patch, it's on the wrong ticket.

pfischer merged https://gitlab.wikimedia.org/repos/search-platform/cirrus-streaming-updater/-/merge_requests/157

Correctly update redirects of existing pages

ebernhardson opened https://gitlab.wikimedia.org/repos/search-platform/cirrus-rerender/-/merge_requests/1

Implement ndjson event source

kicked off rerenders for all pages that have a : in the redirect.title field, based on the latest search index loaded into hadoop on the 26th. That should rerender any page with bad redirect data, along with a some number of pages that have legitimate : in the redirect titles. Unfortunately the dump is from the 26th and the fix was deployed on the 27th, but pulling the data directly from elasticsearch is simply too expensive as we can only find that by running regex queries.

This is estimated to take ~3 hours to rerender, will check in after that.

rerenders are complete, example replication query looks to be fixed.

dcausse merged https://gitlab.wikimedia.org/repos/search-platform/cirrus-rerender/-/merge_requests/1

Implement ndjson event source

Is this supposed to be fixed?

(Edit: link.)

Edit 2: apparently this is a different error since the pages did in fact exist.

In T372446#10123245, @1234qwer1234qwer4 wrote:

Is this supposed to be fixed?

(Edit: link.)

Edit 2: apparently this is a different error since the pages did in fact exist.

All the other pages i was able to look up also existed at one point, the problem here is generally described as cross-namespace redirects being incorrectly indexed, and then not being cleaned up when the redirect was removed because it wasn't where it was expected to be in the search index

So the first example there is of Hipps_Boson/sandbox -> Sarah Wayland. It looks like Hipps_Boson/sandbox was the original location of that page, and it was then moved to Sarah Wayland. I'll have to look closer to see what exactly happened there and how that managed to get indexed that way.

Change #1071267 had a related patch set uploaded (by Ebernhardson; author: Ebernhardson):

[mediawiki/extensions/CirrusSearch@master] [WIP] Drop matches from bad redirects, and count them

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

The patch to count should be merged soon-ish. Need to decide where it goes, probably into the Elasticsearch Indexing dashboard

Change #1071267 merged by jenkins-bot:

[mediawiki/extensions/CirrusSearch@master] Count matches from bad redirects

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

Graph added to elasticsearch indexing dashboard: https://grafana.wikimedia.org/d/JLK3I_siz/elasticsearch-indexing?orgId=1&viewPanel=60

Graphed results are a little surprising, worse than I would have hoped for, but also not all that bad. We receive ~20-30 results each hour that get excluded from the results. Another 20-30 results per hour are now having the non-existent redirect stripped. Of those ~5 results per hour might have only matched due to the redirect and are now a bit mysterious. Given that full text search does 300-500 req/s, which gives a lower bound of perhaps 20M pages inspected per hour, that is an still an incredibly small fraction.