In all the cases I've been able to find, the section in the red link actually exists, so I think this may be a problem with the link checking rather than out-of-date search indexes.

Bisected and looks like it's caused by 9e49260fc9586c962f8c4da64ff4c0f355c19a07

In T285951#7190469, @dcausse wrote:

Bisected and looks like it's caused by 9e49260fc9586c962f8c4da64ff4c0f355c19a07

That was my suspicion as well. I'll look into it asap.

@dcausse is there a way for me to test this locally without having to set up the full Cirrus stack?

@daniel this rendering should be wholy outside cirrus, should be testable with bare mediawiki. The link rendering calls all happen from includes/search/searchwidgets in core

In T285951#7190506, @EBernhardson wrote:

@daniel this rendering should be wholy outside cirrus, should be testable with bare mediawiki. The link rendering calls all happen from includes/search/searchwidgets in core

Hmm, actually i misspoke. While the rendering is in core, core doesn't provide sections in the results. Hmm, in that case you pretty much have to have an MWV instance arround, or hack something up to provide a section anyways.

In T285951#7190530, @EBernhardson wrote:

Hmm, actually i misspoke. While the rendering is in core, core doesn't provide sections in the results. Hmm, in that case you pretty much have to have an MWV instance arround, or hack something up to provide a section anyways.

I will try to cook up a test case. It's not clear to me what's happening here.

If this helps I'm seeing:

2021-07-01 16:16:50 wiki LinkCache WARNING: non-proper page reference {"page-reference":{"Title":"Test"}}

in my logs.

It does seem to be some interaction between the search results page and the link checking. I can't find any instances on affected wikis of incorrect red section links on regular wiki pages.

In T285951#7190572, @dcausse wrote:

If this helps I'm seeing:

2021-07-01 16:16:50 wiki LinkCache WARNING: non-proper page reference {"page-reference":{"Title":"Test"}}

in my logs.

@dcausse can you insert a var_dump( $page) in LinkCache:L153, right before this warning, and maybe a stack trace?

In T285951#7190572, @dcausse wrote:

If this helps I'm seeing:

2021-07-01 16:16:50 wiki LinkCache WARNING: non-proper page reference {"page-reference":{"Title":"Test"}}

in my logs.

That's curious... Is this for a hit on a page called "Test" in the main namespace?

As a workaround, what if we always render the link as a known one?

diff --git a/includes/search/searchwidgets/FullSearchResultWidget.php b/includes/search/searchwidgets/FullSearchResultWidget.php
index 7b79e1861a..9905781581 100644
--- a/includes/search/searchwidgets/FullSearchResultWidget.php
+++ b/includes/search/searchwidgets/FullSearchResultWidget.php
@@ -168,7 +168,7 @@ protected function generateMainLinkHtml( SearchResult $result, $position ) {
 	protected function generateAltTitleHtml( $msgKey, ?Title $title, $text ) {
 		$inner = $title === null
 			? $text
-			: $this->linkRenderer->makeLink( $title, $text ? new HtmlArmor( $text ) : null );
+			: $this->linkRenderer->makeKnownLink( $title, $text ? new HtmlArmor( $text ) : null );
 
 		return "<span class='searchalttitle'>" .
 				$this->specialPage->msg( $msgKey )->rawParams( $inner )->parse()

The function is apparently called for redirects, sections, and (with $title = null) categories; I assume the link target should exist in each of those cases.

In T285951#7190630, @daniel wrote:

In T285951#7190572, @dcausse wrote:

If this helps I'm seeing:

2021-07-01 16:16:50 wiki LinkCache WARNING: non-proper page reference {"page-reference":{"Title":"Test"}}

in my logs.

That's curious... Is this for a hit on a page called "Test" in the main namespace?

No it's on my local wiki.

Ok, so LinkRenderer is looking whether the Title exists or not to decide whether the link is blue or red. After Daniel's patch, we short-circuit this check on Title::canExist - if the title can not exist, it's certainly doesn't exist.

Title::canExist checks if Title is valid - invalid title can not exist. But from the var_dump @dcausse has posted, Title::mIsValid is false! - thus the link is red. Now to figure out why is this title invalid.

In T285951#7190689, @Pchelolo wrote:

But from the var_dump @dcausse has posted, Title::mIsValid is false! - thus the link is red. Now to figure out why is this title invalid.

Oh, good find, I didn't spot that! This is rather strange.

The title decides that it's invalid because mFragment is 'Test_test_hop' and MWTitleCodec returns fragment as 'Test test hop'. Title::isValid expects exact string match of re-parsed title parts. Boom!

In T285951#7190635, @dcausse wrote:

That's curious... Is this for a hit on a page called "Test" in the main namespace?

No it's on my local wiki.

Yea, is it a hit for a page called "Test" in the main namespace or your wiki?

Also... could you hack it to get a stack trace?

In T285951#7190721, @Pchelolo wrote:

The title decides that it's invalid because mFragment is 'Test_test_hop' and MWTitleCodec returns fragment as 'Test test hop'. Title::isValid expects exact string match of re-parsed title parts. Boom!

Ohh... and how does that mFragment get in there? Via Title::makeTitle?

That's the only place I can find where we don't normalize fragment. Unless cirrus does something like saving serialized titles and unserializing them..

Change 702699 had a related patch set uploaded (by Ppchelko; author: Ppchelko):

[mediawiki/core@master] Consistently normalize Title::mFragment before setting

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

The titles should generaly come from TitleHelper::makeTitle. The namespace and title values passed through are the same as those found in ?action=cirrusdump for any page. The fragment is not yet included there though, it is added from HighlightingTrait::findSectionTitle using Title::createFragmentTarget

Could someone with Cirrus setup test the patch above - I believe it will take care of the problem, but since it's urgent and I don't have cirrus setup locally, so it will probably be faster to ask for help here.

In T285951#7190778, @Pchelolo wrote:

Could someone with Cirrus setup test the patch above - I believe it will take care of the problem, but since it's urgent and I don't have cirrus setup locally, so it will probably be faster to ask for help here.

Seems to work, section is no longer red.

Change 702702 had a related patch set uploaded (by Daniel Kinzler; author: Daniel Kinzler):

[mediawiki/core@master] Improve logging in LinkCache.

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

Change 702699 merged by jenkins-bot:

[mediawiki/core@master] Consistently normalize Title::mFragment before setting

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

Change 702711 had a related patch set uploaded (by Brennen Bearnes; author: Ppchelko):

[mediawiki/core@wmf/1.37.0-wmf.12] Consistently normalize Title::mFragment before setting

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

Change 702711 merged by jenkins-bot:

[mediawiki/core@wmf/1.37.0-wmf.12] Consistently normalize Title::mFragment before setting

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

Confirmed fixed on mwdebug2001; synching.

Mentioned in SAL (#wikimedia-operations) [2021-07-01T19:34:14Z] <brennen@deploy1002> Synchronized php-1.37.0-wmf.12/includes/Title.php: Backport: [[gerrit:702711|Consistently normalize Title::mFragment before setting (T285951)]] (duration: 01m 10s)

Mentioned in SAL (#wikimedia-operations) [2021-07-01T19:35:57Z] <brennen@deploy1002> Synchronized php-1.37.0-wmf.12/tests/phpunit/includes/TitleMethodsTest.php: Backport: [[gerrit:702711|Consistently normalize Title::mFragment before setting (T285951)]] (duration: 01m 10s)

Resolved?

In T285951#7190789, @gerritbot wrote:

Change 702702 had a related patch set uploaded (by Daniel Kinzler; author: Daniel Kinzler):

[mediawiki/core@master] Improve logging in LinkCache.

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

This patch hasn’t been merged yet. Are we still interested in it? Otherwise I think we can close this task.

Change 702702 merged by jenkins-bot:

[mediawiki/core@master] Improve logging in LinkCache.

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

@brennen , it looks like this ticket was reopened. I believe you(r team) worked on this last. Please let us know if this needs to be looked at by the Search team

@brennen , it looks like this ticket was reopened. I believe you(r team) worked on this last. Please let us know if this needs to be looked at by the Search team

RelEng involvement here was limited to train coordination and backport deployment. This is probably a question for @daniel et al.

I just looked at it for 15 minutes, and I can't see why this is broken, but other section titles with spaces and non-ascii chars work fine. I'll see if I can find some time to dig deeper next week.

thanks @daniel, if we are not able to get further next week, it will have to go into the backlog. Given it's priority it will likely take sometime to get to this issue.

Additional example: https://ru.wikipedia.org/w/index.php?search="середина+XIX+века+(греческий+период)"

Another one, all ASCII characters.

https://en.wikipedia.org/w/index.php?search=%22discontinuation+of+the+first+brand+extension%22+prefix%3AWikipedia%3AReference+desk%2FArchives%2FEntertainment

In T285951#7996312, @Nardog wrote:

Another one, all ASCII characters.

https://en.wikipedia.org/w/index.php?search=%22discontinuation+of+the+first+brand+extension%22+prefix%3AWikipedia%3AReference+desk%2FArchives%2FEntertainment

Though it's not just ASCII characters. There are double quotes in the section title, and they can cause all sorts of escaping problems. That's an excellent test case!

This doesn't even include quotes.
https://en.wikipedia.org/w/index.php?search=%22Society+of+the+Snow%22+prefix%3A%22User+talk%3AIdoghor+Melody%22

Another similar one, if it helps: https://de.wikipedia.org/w/index.php?search="Essays%2C+Reden%2C+Propagandaschriften+u.+a."

In T285951#8169569, @Nardog wrote:

This doesn't even include quotes.
https://en.wikipedia.org/w/index.php?search=%22Society+of+the+Snow%22+prefix%3A%22User+talk%3AIdoghor+Melody%22

The section heading ends in a left-to-right-mark (U+200E)

In T285951#8315719, @1234qwer1234qwer4 wrote:

Another similar one, if it helps: https://de.wikipedia.org/w/index.php?search="Essays%2C+Reden%2C+Propagandaschriften+u.+a."

The section heading ends in u.&nbsp;a.

All reported examples which still fail have something other than ASCII letters, digits, spaces and periods in the heading. T368592 reports the issue for headings ending in a space followed by a question mark, but not a letter followed by a question mark, so it's apparently not solely about the presence of a special character.

Another example without quotes: https://ru.wikipedia.org/w/index.php?search=Туркменистан&prefix=Википедия%3AК+переименованию&title=Служебная:Поиск&profile=advanced&fulltext=1&ns4=1