Maniphest T208924

PHP Fatal from querypage API: Argument passed to SpecialEntityUsage::__construct must implement EntityIdParser
Closed, ResolvedPublic8 Estimated Story PointsPRODUCTION ERROR
Actions

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)

Details

Subject	Repo	Branch	Lines +/-
Clean up QueryPage subclass handling	mediawiki/extensions/Wikibase	master	+3 -5
Remove unintended api special page ➜ fix fatal error	mediawiki/extensions/Wikibase	master	+0 -2
Add EntityUsage to $wgAPIUselessQueryPages	mediawiki/extensions/Wikibase	master	+1 -0

Customize query in gerrit

Related Objects

Mentioned Here: rMWf54029806dad: Use SpecialPageFactory in ApiQueryQueryPage
T144923: Add special page to show entity usage in client

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

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.

Addshore added a project: Wikidata-Campsite.Nov 7 2018, 9:44 AM

Addshore moved this task from Incoming to Ready to estimate on the Wikidata-Campsite board.

Addshore moved this task from incoming to consider for next sprint on the Wikidata board.

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-Action-API board.Nov 7 2018, 2:47 PM

Lucas_Werkmeister_WMDE set the point value for this task to 8.Dec 11 2018, 3:55 PM

Lucas_Werkmeister_WMDE moved this task from Ready to estimate to Wikidata-Campsite-Iteration-∞ (On Hold) on the Wikidata-Campsite board.

Lucas_Werkmeister_WMDE edited projects, added Wikidata-Campsite (Wikidata-Campsite-Iteration-∞ (On Hold)); removed Wikidata-Campsite.

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

Michael moved this task from To Do (prioritised from top to bottom) to Doing on the Wikidata-Campsite (Wikidata-Campsite-Iteration-∞ (On Hold)) board.Dec 12 2018, 9:28 AM

Michael moved this task from 🗃️ Incoming to ⏳ In progress on the User-Michael board.

Addshore subscribed.Dec 12 2018, 12:29 PM

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

gerritbot added a project: Patch-For-Review.Dec 12 2018, 12:51 PM

Michael moved this task from Doing to Peer Review on the Wikidata-Campsite (Wikidata-Campsite-Iteration-∞ (On Hold)) board.Dec 12 2018, 2:59 PM

Michael moved this task from ⏳ In progress to 💬 waiting on other's work or feedback on the User-Michael board.

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

ReleaseTaggerBot added a project: MW-1.33-notes (1.33.0-wmf.9; 2018-12-18).Dec 13 2018, 3:00 PM

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

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

Lucas_Werkmeister_WMDE moved this task from Peer Review to Doing on the Wikidata-Campsite (Wikidata-Campsite-Iteration-∞ (On Hold)) board.Dec 14 2018, 11:04 AM

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

Lucas_Werkmeister_WMDE moved this task from Doing to Peer Review on the Wikidata-Campsite (Wikidata-Campsite-Iteration-∞ (On Hold)) board.Dec 14 2018, 4:01 PM

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

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

Addshore moved this task from Peer Review to Test (Verification) on the Wikidata-Campsite (Wikidata-Campsite-Iteration-∞ (On Hold)) board.Dec 18 2018, 10:39 AM

Michael moved this task from 💬 waiting on other's work or feedback to ✅ my work done on the User-Michael board.Dec 18 2018, 12:43 PM

Addshore moved this task from consider for next sprint to in progress on the Wikidata board.Dec 19 2018, 12:44 PM

Moving to "done" on the MediaWiki-Action-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.

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

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

Maintenance_bot removed a project: Patch-For-Review.Aug 28 2019, 11:30 PM

Krinkle moved this task from Since Nov 2018 / 1.33.wmf2 to Resolved on the Wikimedia-production-error board.Sep 10 2019, 2:31 AM

Aklapper removed a subscriber: Anomie.Oct 16 2020, 5:40 PM

PHP Fatal from querypage API: Argument passed to SpecialEntityUsage::__construct must implement EntityIdParserClosed, ResolvedPublic8 Estimated Story PointsPRODUCTION ERRORActions