Page MenuHomePhabricator

PHP Fatal from querypage API: Argument passed to SpecialEntityUsage::__construct must implement EntityIdParser
Closed, ResolvedPublic8 Story Points

Description

Error

Request ID: W@I-EQpAIDkAAICw1wsAAADB

message
PHP Fatal Error: Argument 1 passed to Wikibase\Client\Specials\SpecialEntityUsage::__construct() must implement interface Wikibase\DataModel\Entity\EntityIdParser, undefined variable given
trace
#0 /srv/mediawiki/php-1.33.0-wmf.2/includes/api/ApiQueryQueryPage.php(129): NO_FUNCTION_GIVEN()
#1 /srv/mediawiki/php-1.33.0-wmf.2/includes/api/ApiQuery.php(248): ApiQueryQueryPage->getCacheMode(array)
#2 /srv/mediawiki/php-1.33.0-wmf.2/includes/api/ApiMain.php(1570): ApiQuery->execute()
#3 /srv/mediawiki/php-1.33.0-wmf.2/includes/api/ApiMain.php(531): ApiMain->executeAction()
#4 /srv/mediawiki/php-1.33.0-wmf.2/includes/api/ApiMain.php(502): ApiMain->executeActionWithErrorHandling()
#5 /srv/mediawiki/php-1.33.0-wmf.2/api.php(87): ApiMain->execute()
#6 /srv/mediawiki/w/api.php(3): include(string)

Impact

User queries to API with list=querypage&qppage=EntityUsage are aborted with the above fatal error. Seen in production from at least the following three example urls:

  • https://en.wikipedia.org/w/api.php?action=query&list=querypage&qppage=EntityUsage&qplimit=10
  • https://ko.wikipedia.org/w/api.php?action=query&list=querypage&qppage=EntityUsage&qplimit=10
  • https://www.wikidata.org/w/api.php?action=query&list=querypage&qppage=EntityUsage&qplimit=10

The GUI version of the same special page, works fine. For example at https://ko.wikipedia.org/wiki/Special:EntityUsage.

Notes

There is a second error consistently paired with this one, logged right before the fatal:

message
PHP Warning: __construct() expects exactly 1 parameter, 0 given

#0 /srv/mediawiki/php-1.33.0-wmf.2/extensions/Wikibase/client/includes/Specials/SpecialEntityUsage.php(45): MWExceptionHandler::handleError(integer, string, string, integer, array, array)
#1 /srv/mediawiki/php-1.33.0-wmf.2/includes/api/ApiQueryQueryPage.php(129): Wikibase\Client\Specials\SpecialEntityUsage->__construct()
#2 /srv/mediawiki/php-1.33.0-wmf.2/includes/api/ApiQuery.php(248): ApiQueryQueryPage->getCacheMode(array)
#3 /srv/mediawiki/php-1.33.0-wmf.2/includes/api/ApiMain.php(1570): ApiQuery->execute()
#4 /srv/mediawiki/php-1.33.0-wmf.2/includes/api/ApiMain.php(531): ApiMain->executeAction()
#5 /srv/mediawiki/php-1.33.0-wmf.2/includes/api/ApiMain.php(502): ApiMain->executeActionWithErrorHandling()
#6 /srv/mediawiki/php-1.33.0-wmf.2/api.php(87): ApiMain->execute()
#7 /srv/mediawiki/w/api.php(3): include(string)

Event Timeline

Krinkle created this task.Nov 7 2018, 1:34 AM
Restricted Application added subscribers: revi, Aklapper. · View Herald TranscriptNov 7 2018, 1:34 AM
Krinkle triaged this task as High priority.Nov 7 2018, 1:35 AM

Tentatively triaging as High priority because this exposes a fatal error from a public url via the GET method ("Wikimedia Error" page, HTTP 5xx status code, not cacheable). Which poses a load risk and contributes to the causes of false SRE alarms about cluster stability.

Anomie added a subscriber: Anomie.

There's a decent chance that the 2010-era code in ApiQueryQueryPage could use updating in some manner.

$qp = new $this->qpMap[$params['page']]();

It should probably use SpecialPageFactory somehow instead.

Anomie moved this task from Unsorted to Needs Code on the MediaWiki-API board.Nov 7 2018, 2:47 PM
Michael claimed this task.Dec 12 2018, 9:27 AM
Restricted Application added a project: User-Michael. · View Herald TranscriptDec 12 2018, 9:27 AM

It looks like that special page was never intended to be used from list=querypage (no mention of this in T144923: Add special page to show entity usage in client), so removing that support is probably the simplest option.

Change 479194 had a related patch set uploaded (by Michael Große; owner: Michael Große):
[mediawiki/extensions/Wikibase@master] Remove unintended api special page ➜ fix fatal error

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

Change 479240 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/Wikibase@master] Add EntityUsage to $wgAPIUselessQueryPages

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

I guess only one of the changes, either 479194 or 479240, should move forward. Both seem to resolve the issue.

Change 479240 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Add EntityUsage to $wgAPIUselessQueryPages

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

Change 479194 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Remove unintended api special page ➜ fix fatal error

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

As far as I can tell, the QueryPage class does at least four things:

  • manage an SQL query with user-configurable offset and limit, and display the list of pages it returns as a special page
  • optionally, cache the results (opt out by overriding isCacheable)
  • optionally, present the results as an RSS feed (opt out by overriding isSyndicated)
  • optionally, include the special page in a list of query pages (opt out by not adding the page to $wgQueryPages), which is used by…
    • optionally, list=querypage to expose the results as an API module (opt out by adding the page to $wgUselessQueryPages)
    • maintenance/updateSpecialPages.php to update cached results

Since we’re not interested in caching, I don’t think it makes a difference whether we use $wgQueryPages or $wgUselessQueryPages, but conceptually I guess the former makes more sense, both for EntityUsage and for PagesWithBadges. (However, the maintenance script goes through SpecialPageFactory to instantiate the special pages, so it doesn’t crash anyways. Updating ApiQueryQueryPage to do the same would make sense regardless.)

That said, perhaps parts of QueryPage should also be split off so that we don’t need to carry this whole baggage that doesn’t make sense in our situation… a base class QueryResultsPage, just for the first bullet point? Not sure. But probably not in scope for this task anyways.

Change 479716 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/Wikibase@master] Clean up QueryPage subclass handling

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

Change 479716 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Clean up QueryPage subclass handling

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

Anomie moved this task from Needs Code to Done on the MediaWiki-API board.EditedDec 19 2018, 3:10 PM

Moving to "done" on the MediaWiki-API workboard per rMWf54029806dad: Use SpecialPageFactory in ApiQueryQueryPage. That didn't solve this task itself, but does address the identified shortcoming in the core API code.

Addshore closed this task as Resolved.Dec 20 2018, 11:28 AM

Not quite deployed to group2 yet, but this has already fixed group1 and will continue to roll out with the train.