Assuming this task is about the mediawiki-parser code project, hence adding that project tag so other people who don't know or don't care about team tags can also find this task when searching via projects.

In T261347#6485128, @Krinkle wrote:

Woops, this crash is easily reproducible at https://diq.wikipedia.org/wiki/Vaten:%C4%B0lm.

Content is:

#REDIRECT [[Talk:Portal:Zanayış]]

And https://diq.wikipedia.org/wiki/Talk:Portal:Zanay%C4%B1%C5%9F returns:

Bad title
The requested page title refers to a talk page that cannot exist.

In T261347#6485210, @bd808 wrote:

And https://diq.wikipedia.org/wiki/Talk:Portal:Zanay%C4%B1%C5%9F returns:

Bad title
The requested page title refers to a talk page that cannot exist.

Yes, https://en.wikipedia.org/wiki/Talk:User:X also currectly returns this. The subject page of Talk:User:X would be User:X, but the talk page of User:X is User_talk:X. There cannot be a page for which the talk page is Talk:User:X. This part works as designed.

However, why does the redirect trigger a fatal error? https://en.wikipedia.org/wiki/User:DKinzler_(WMF)/T261347 doesn't, it's just not a redirect.

This is not an issue with the parser, but rather with the output logic toward the skin.

I'm not sure about that.

ParserOutput::getText() is trying to inject [edit] section links nased on '<mw:editsection>' placeholders emitted by the parser. The exception is caused by Title::newFromText( htmlspecialchars_decode( $m[1] ) ) returning null for an invalid title. That title comes from $editlink = '<mw:editsection page="' . htmlspecialchars( $editsectionPage ) in Parser. $editsectionPage usually comes from $this->getTitle()->getPrefixedText(), which should never be invalid.

Also... how would https://diq.wikipedia.org/wiki/Vaten:%C4%B0lm even trigger edit section links?

Hm, why is the patch not being linked to the ticket? Anyway, here is a patch that makes ParserOutput log an error instead of throwing. This way, we can continue investigating without user impact.

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/629421

Note:

• The fatal error happens while the destination of the redirect is attempted to be rendered, not the one in the URL. ("Soft redirects").
• Viewing the latest revision of the URL directly, via https://diq.wikipedia.org/w/index.php?title=Vaten:%C4%B0lm&oldid=44966 does not produce an error because that is merely asking to render the redirect code itself. And interestingly, that is not producing a clickable link because it is an invalid link target. It instead falls back to the expected plain text rendering.
• Given this rendering behaviour the question then becomes: How come this was saved in a way that instructed MediaWiki to store a redirect in the database? If you purge this title or save the same wikitext elsewhere, it would not produce a redirect and thus be fine.
• I suspect the root cause here is that maybe namespaces or localisation thereof changed on the wiki, and we did not run the neccecary scripts such as namespaceDupes.php or some such. Or maybe we did, but the script has a blind spot that is failing to have converted/fixed this?
• Is checkBadRedirects.php relevant?
• We can probably tolerate a more graceful failure here since there's an established fallback for this sort of scenario, namely to render it as plain text.

Some things we could do now:

• Find root cause.
• Then fix root cause if it's a new issue, or if we just forgot to run scripts, run them.
• Make this failure more graceful, render as escaped/plain text?

> select * from redirect where rd_from = 8156 \G
*************************** 1. row ***************************
     rd_from: 8156
rd_namespace: 1
    rd_title: Portal:Zanayış
rd_interwiki: 
 rd_fragment: 
1 row in set (0.05 sec)

Indeed, the page is recorded in the database as a redirect. And purging would probably fix the issue. Please don't do that just yet though, having a way to reproduce is useful.

I suppose this redirect was created when "Portal:" was just a prefix in the main namespace, so the talk page would have been "Talk:Portal:Xyz". When the Portal namespace was created, this link was not fixed. Does namespaceDupes even try to detect this case?

What I find strange is the way this confuses the parser. I'll try to re-create it locally.

In T261347#6487839, @daniel wrote:

Hm, why is the patch not being linked to the ticket?

Because this ticket is not public.

Locally creating a page that redirects to Talk:Portal:X, and then creating the Portal namespace and running namespaceDupes indeed leaves the bad row in the database.
However, I can't reproduce the hard failure this way. The page just renders as plain wikitext, as would be expected.

Fix submitted: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/666507

I don't think reproducible exceptions need to be private tasks. It's a nuisance, and the worst case impact is not that bad.

Should the namespaceDupes.php script be fixed so that it does not leave behind bad redirect rows? I suppose the extra pass through the redirect table would make the script much slower, but I'd prefer that to leaving broken entries in the database.

Change 666507 merged by jenkins-bot:
[mediawiki/core@master] Safer WikiPage redirect functions

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