Page MenuHomePhabricator

Some pages unavailable due to PostconditionException: makeTitleSafe() should always return a Title
Closed, ResolvedPublicPRODUCTION ERROR

Description

Error
normalized_message
[{reqId}] {exception_url}   Wikimedia\Assert\PostconditionException: Postcondition failed: makeTitleSafe() should always return a Title for the text returned by getRootText().

Variation for getBaseText():

Wikimedia\Assert\PostconditionException: Postcondition failed: makeTitleSafe() should always return a Title for the text returned by getBaseText().
exception.trace
from /srv/mediawiki/php-1.37.0-wmf.21/vendor/wikimedia/assert/src/Assert.php(202)
#0 /srv/mediawiki/php-1.37.0-wmf.21/includes/Title.php(2053): Wikimedia\Assert\Assert::postcondition(boolean, string)
#1 /srv/mediawiki/php-1.37.0-wmf.21/includes/skins/Skin.php(518): Title->getRootTitle()
#2 /srv/mediawiki/php-1.37.0-wmf.21/skins/MinervaNeue/includes/Skins/SkinMinerva.php(241): Skin->getPageClasses(Title)
#3 /srv/mediawiki/php-1.37.0-wmf.21/includes/OutputPage.php(3147): SkinMinerva->getPageClasses(Title)
#4 /srv/mediawiki/php-1.37.0-wmf.21/includes/skins/SkinTemplate.php(440): OutputPage->headElement(SkinMinerva)
#5 /srv/mediawiki/php-1.37.0-wmf.21/skins/MinervaNeue/includes/Skins/SkinMinerva.php(125): SkinTemplate->prepareQuickTemplate()
#6 /srv/mediawiki/php-1.37.0-wmf.21/skins/MinervaNeue/includes/Skins/SkinMinerva.php(78): SkinMinerva->prepareQuickTemplate()
#7 /srv/mediawiki/php-1.37.0-wmf.21/includes/skins/SkinMustache.php(56): SkinMinerva->getTemplateData()
#8 /srv/mediawiki/php-1.37.0-wmf.21/includes/skins/SkinTemplate.php(150): SkinMustache->generateHTML()
#9 /srv/mediawiki/php-1.37.0-wmf.21/includes/OutputPage.php(2644): SkinTemplate->outputPage()
#10 /srv/mediawiki/php-1.37.0-wmf.21/includes/MediaWiki.php(939): OutputPage->output(boolean)
#11 /srv/mediawiki/php-1.37.0-wmf.21/includes/MediaWiki.php(952): MediaWiki::{closure}()
#12 /srv/mediawiki/php-1.37.0-wmf.21/includes/MediaWiki.php(559): MediaWiki->main()
#13 /srv/mediawiki/php-1.37.0-wmf.21/index.php(53): MediaWiki->run()
#14 /srv/mediawiki/php-1.37.0-wmf.21/index.php(46): wfIndexMain()
#15 /srv/mediawiki/w/index.php(3): require(string)
#16 {main}
Impact
Notes
  • Easily reproducible via the (redacted) url -- seems like unexpected/unhandled user input

Event Timeline

Tagged @Jdlrobson specifically because phab didn't complete a likely looking team tag for #reading -- what the tag I should be using?

Looks like this also applies to the Vector skin so it's an issue in mediawiki core.

Jdlrobson triaged this task as Medium priority.Sep 2 2021, 7:24 PM
Jdlrobson removed a project: Reading-Admin.
Jdlrobson lowered the priority of this task from Medium to Low.EditedSep 3 2021, 7:42 PM
Jdlrobson added a subscriber: Pchelolo.

? Looking closely, it doesn't seem like an issue in the skin code but inside the Title or OutputPage code which are out of the scope of my team (not sure of appropriate tag).... @Pchelolo perhaps you have an idea of what is happening here or maybe someone in platform engineering/traffic?

There are only 3 instances of this error in the last 7 days and it only seems to be impacting mediawiki.org and it's impacting both desktop and mobile site.

It is possible to get the page name or a non-redacted url? If there is a problem with something in the url: it is possible to create a fake one which fatals by replacing some letters?

It is hard to tell without example, why a title fails normalization when everything behind the first / is removed.

Zabe added subscribers: MdsShakil, Zabe, Aishik_Rehman, Yahya.

It is possible to get the page name or a non-redacted url? If there is a problem with something in the url: it is possible to create a fake one which fatals by replacing some letters?

It is hard to tell without example, why a title fails normalization when everything behind the first / is removed.

You can find a link in the task description of the duplicate task.

It is possible to get the page name or a non-redacted url? If there is a problem with something in the url: it is possible to create a fake one which fatals by replacing some letters?

It is hard to tell without example, why a title fails normalization when everything behind the first / is removed.

You can find a link in the task description of the duplicate task.

That is a namespace issue due to (bad) config and missing cleanup after config change.

https://bn.wikibooks.org/w/api.php?action=query&titles=%E0%A6%86%E0%A6%B2%E0%A6%BE%E0%A6%AA:%E0%A6%B0%E0%A6%A8%E0%A7%8D%E0%A6%A7%E0%A6%A8%E0%A6%AA%E0%A7%8D%E0%A6%B0%E0%A6%A3%E0%A6%BE%E0%A6%B2%E0%A7%80:%E0%A6%A1%E0%A6%BF%E0%A6%AE%20%E0%A6%AD%E0%A6%BE%E0%A6%9C%E0%A6%BF

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

Change 740315 had a related patch set uploaded (by Umherirrender; author: Umherirrender):

[mediawiki/core@master] Replace Title::getRootTitle with TitleFormatter in Skin::getPageClasses

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

There is no way to avoid this exception, because the invalid title is already there. Just avoid the title object to avoid the bad title which throws the exception here.

In a perfect world this is not needed, but due to config changes there are situation where this can happen for short or long periodes.

@Umherirrender Is it possible to delete the two pages I mentioned (T296131) from the server side?

@Umherirrender Is it possible to delete the two pages I mentioned (T296131) from the server side?

It is not possible to delete them normally with the wiki UI. api.php can handle pages by pageid and it could be possible to move the page (without redirect by sysop) or to delete the page (by sysop) with Special:ApiSandbox or by direct api calls.
The other solutation is to request a run of namespaceDupes.php for that wiki to fix it from the server side and delete it afterwards.

I trying to delete two pages using python script as instructed here, but results was failed (called two pages was not exist). I have no idea how to use mw api

I trying to delete two pages using python script as instructed here, but results was failed (called two pages was not exist). I have no idea how to use mw api

You can try

Press "make request" and fill in the "token" by pressing "correct token and submit". That would also use the api. If you want use the python you have to replace 'title':"enter_a_page_title" with 'pageid': <number> and put in the number of curid on the url. The reason in the link is Page not reachable - [[phab:T296131]], but could be changed as needed.

Krinkle renamed this task from Wikimedia\Assert\PostconditionException: Postcondition failed: makeTitleSafe() should always return a Title for the text returned by getRootText(). to Some pages unavailable due to PostconditionException: makeTitleSafe() should always return a Title.Mar 15 2022, 12:35 AM
Krinkle updated the task description. (Show Details)

Change 740315 merged by jenkins-bot:

[mediawiki/core@master] skins: Change Skin::getPageClasses to avoid Title::getRootTitle

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

Still fails after the patch is deployed. But it shows the error handling of mediawiki and not the white error page of Wikimedia. That means the skin building code now passed, but something other still calls function which fails.

Would be nice to see the next stacktrace

[dee62ec0-7073-4021-a2d3-2e1e46e967f8] 2022-04-20 18:05:11: Errore irreversibile di tipo "Wikimedia\Assert\PostconditionException"

class includes now page-Speciale_Badtitle_NS104_Destinazioni rootpage-Speciale_Badtitle_NS104_Destinazioni

Krinkle added subscribers: BPirkle, daniel, Umherirrender.

These revisions have been broken for two years now.

The assertion was added for T225585

Indeed, introduced in:

Change 517014 merged by jenkins-bot:
[mediawiki/core@master] Title: ensure getBaseTitle and getRootTitle return valid Titles

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

/cc @daniel @BPirkle. Tagging API Platform for ease of discovery (ince you both moved to that team, and Title.php isn't explicitly part of any component).

Aforementioned URLs are broken with a Fatal Error on each page view. This is a regression from the Title factor carried out by the former Core Platform Team (led by @daniel at the time, I believe).

While reported the inbox of several incarnations of CPT and later API Platform, the regression remains untriaged (much less fixed). Tagging MediaWiki-Engineering group for fallback triage.

That is a namespace issue due to (bad) config and missing cleanup after config change.

Correct. This happens when a revision ID is given that points to a revision that belongs to a page that is in a namespace that doesn't exist anymore. E.g. https://it.wikivoyage.org/w/index.php?title=Dummy&oldid=712466 is in namespace 104 which was removed two weeks ago, see r952817 and T298315 and T145328.

There are 226 pages left in that namespace, all redirects. We should probably have a script for mass-deleting pages like this. There is a nother ticket somewhere with the same root cause that I investigated a couple of weeks ago.

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

[mediawiki/core@master] Title: be more robust when handling invalid titles

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

We should perhaps also think about how we could be more lenient. Invalid namespaces are always bound to cause problems, but we could avoid this specific issue easily enough. See the patch I just posted.

Change 1006053 merged by jenkins-bot:

[mediawiki/core@master] Title: be more robust when handling invalid titles

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

Still fails after the patch is deployed. But it shows the error handling of mediawiki and not the white error page of Wikimedia. That means the skin building code now passed, but something other still calls function which fails.

The page is now accessible with title Speciale:Badtitle/NS104:Destinazioni, that is another issue. The fatal is gone, task is resolved.