Page MenuHomePhabricator

2018-04-06 13:43:57: Fatal exception of type "Wikimedia\Assert\ParameterTypeException"
Closed, ResolvedPublicPRODUCTION ERROR

Description

Spotted in production with details as follows:

Error message:
[Wsd5nQpAICkAACuB7V0AAAAA] 2018-04-06 13:43:57: Fatal exception of type "Wikimedia\Assert\ParameterTypeException"

URL
https://www.wikidata.org/w/index.php?title=Special%3AItemByTitle&site=enwiki&page=Categor%C3%ADa%3AProtecci%C3%B3n+de+datos

Stacktrace:

Bad value for parameter $pageTitle: must be a string
#0 /srv/mediawiki/php-1.31.0-wmf.28/extensions/Wikibase/lib/includes/Store/Sql/SiteLinkTable.php(216): Wikimedia\Assert\Assert::parameterType(string, boolean, string)
#1 /srv/mediawiki/php-1.31.0-wmf.28/extensions/Wikibase/repo/includes/Specials/SpecialItemByTitle.php(125): Wikibase\Lib\Store\Sql\SiteLinkTable->getItemIdForLink(string, boolean)
#2 /srv/mediawiki/php-1.31.0-wmf.28/includes/specialpage/SpecialPage.php(522): Wikibase\Repo\Specials\SpecialItemByTitle->execute(string)
#3 /srv/mediawiki/php-1.31.0-wmf.28/includes/specialpage/SpecialPageFactory.php(568): SpecialPage->run(string)
#4 /srv/mediawiki/php-1.31.0-wmf.28/includes/MediaWiki.php(288): SpecialPageFactory::executePath(Title, RequestContext)
#5 /srv/mediawiki/php-1.31.0-wmf.28/includes/MediaWiki.php(861): MediaWiki->performRequest()
#6 /srv/mediawiki/php-1.31.0-wmf.28/includes/MediaWiki.php(524): MediaWiki->main()
#7 /srv/mediawiki/php-1.31.0-wmf.28/index.php(42): MediaWiki->run()
#8 /srv/mediawiki/w/index.php(3): include(string)
#9 {main}

Event Timeline

Another instance:

https://www.wikidata.org/w/index.php?title=Special%3AItemByTitle&site=enwiki&page=Protecci%C3%B3n+de+datos gives
[Wsd6uwpAADgAAICpXDMAAACP] 2018-04-06 13:48:44: Fatal exception of type "Wikimedia\Assert\ParameterTypeException"

It looks like Special:ItemByTitle breaks on (some?) searches.

Edit: not all of this is correct! see later comments

I think this might be what’s happening:

  • Wikibase attempts to normalize the title locally, and look up an item for that title. It fails.
  • Wikibase asks MediaWiki to normalize the title according to the rules of that wiki. ($siteObj->normalizePageName( $page ) in SpecialItemByTitle)
  • $siteObj is a MediaWikiSite (pure guess, but feels likely?), and to normalize the title, it actually uses an API request to the other site (MediaWikiSite::normalizePageName calls MediaWikiPageNameNormalizer::normalizePageName).
  • The API request returns empty data, or some error, or whatever – in any event, MediaWikiPageNameNormalizer::normalizePageName has plenty of opportunities to return false.
  • The false is passed through all the way back to SpecialItemByTitle, where it causes an error because the only declared return type for all of this was string, never bool.

As far as I can tell, this will happen for any Special:ItemByTitle request for a page that doesn’t exist on the remote wiki, since action=query&prop=info&converttitles=true&titles=$pageName (the query that MediaWikiPageNameNormalizer::normalizePageName issues) returns an empty response for such pages.

I hardly expect that this error has always happened – surely we would have noticed sooner? At a guess, I’d say that the most likely cause seems that the API request would in the past have returned a normalized title even for pages that don’t exist, and now it doesn’t anymore?

Please take all of this with a lot of grains of salt :)

At a guess, I’d say that the most likely cause seems that the API request would in the past have returned a normalized title even for pages that don’t exist, and now it doesn’t anymore?

On a local install, such a request returns a proper title. And my MediaWiki is fairly up to date, so perhaps this is a regression in wmf.27 that was already fixed in master?

Sorry, I used the API sandbox incorrectly, the API does return something. But the case is very simple – if the API reports that the page is missing, then MediaWikiPageNameNormalizer::normalizePageName returns false.

The only open question is why this hasn’t come up before? I can’t see any recent changes in the most closely related lines of code. But according to Logstash this first started happening at 2018-03-14…

More specifically, the first occurrence of the message is on 2018-03-14T20:40:46 – a few minutes after group1 to wmf.25 on SAL. Furthermore, .25 is the first branch to contain commit b3fba13f00 (change I0dac6335e3), which added the Assert::parameterType that’s throwing here – @thiemowmde, looks like the hoped-for effect of making errors easier to find has happened :)

Also, what do we do now? Do we update the documentation of core’s normalizePageName functions to make clear that they can also return false, and change SpecialItemByTitle to deal with the false possibility; or should they be changed to not return false anymore?

Change 424629 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/Wikibase@master] Handle normalizePageName() returning non-string values

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

Change 424849 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/core@master] Fix (MediaWiki)Site::normalizePageName return type

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

What would be the alternative when we remove all return false from MediaWikiPageNameNormalizer::normalizePageName? I don't think it should return the unnormalized original string. In my opinion it would need to throw an exception – which means all code that currently expects false would need to be rewritten. I suggest to document the methods returning false.

Change 424629 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Handle normalizePageName() returning non-string values

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

Change 424849 merged by jenkins-bot:
[mediawiki/core@master] Fix (MediaWiki)Site::normalizePageName return type

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

I don't think it should return the unnormalized original string.

Well, at least I see no reason not to return the normalized string when the API actually gave it to us, just because the page happens to be missing. But I guess that’s a separate change.

See https://gerrit.wikimedia.org/r/425076 (I didn’t add a link to this task because I don’t think it’s really a part of this anymore, just a follow-up).

Lucas_Werkmeister_WMDE claimed this task.

No more errors of this type in Logstash since wmf.29, and all follow-up changes have been either abandoned or merged (see https://gerrit.wikimedia.org/r/425527 for the last one). I think we can close this.

mmodell changed the subtype of this task from "Task" to "Production Error".Aug 28 2019, 11:09 PM