Page MenuHomePhabricator

Page rename (Special:MovePage) can throw InvalidArgumentException: Title does not belong to page ID X but actually belong to Y.
Open, NormalPublic

Description

I noticed the following errors (and similar to) while looking at the PHP7 logs

[XMAmggpAICsAAEwlrXgAAABD] /w/index.php?title=Speciaal:PaginaHernoemen&action=submit   InvalidArgumentException from line 100 of /srv/mediawiki/php-1.34.0-wmf.1/includes/Revision/RevisionStoreRecord.php: The given Title does not belong to page ID 1284480 but actually belongs to 1280398

[XL-6RgpAAD4AAI97q5EAAADR] /w/index.php?title=Special:MovePage&action=submit   InvalidArgumentException from line 100 of /srv/mediawiki/php-1.34.0-wmf.1/includes/Revision/RevisionStoreRecord.php: The given Title does not belong to page ID 41989195 but actually belongs to 39994396

After a rough search, it looks like we have about ~3,850 of errors like these in the past 10 days

Similar tasks:

Error
  • Request ID: XO8cRQpAIDEAAL3eYJkAAACI
InvalidArgumentException: The given Title does not belong to page ID 8946238 but actually belongs to 8171110

#0 /srv/mediawiki/php-1.34.0-wmf.6/includes/Revision/RevisionStore.php(1826): MediaWiki\Revision\RevisionStoreRecord->__construct(Title, User, CommentStoreComment, stdClass, MediaWiki\Revision\RevisionSlots, boolean)
#1 /srv/mediawiki/php-1.34.0-wmf.6/includes/Revision/RevisionStore.php(2167): MediaWiki\Revision\RevisionStore->newRevisionFromRow(stdClass, integer, Title)
#2 /srv/mediawiki/php-1.34.0-wmf.6/includes/Revision/RevisionStore.php(1535): MediaWiki\Revision\RevisionStore->loadRevisionFromConds(Wikimedia\Rdbms\DBConnRef, array, integer, Title)
#3 /srv/mediawiki/php-1.34.0-wmf.6/includes/Revision.php(138): MediaWiki\Revision\RevisionStore->getRevisionByTitle(Title, integer, integer)
#4 /srv/mediawiki/php-1.34.0-wmf.6/extensions/PageImages/includes/LinksUpdateHookHandler.php(50): Revision::newFromTitle(Title)
#5 /srv/mediawiki/php-1.34.0-wmf.6/extensions/PageImages/includes/LinksUpdateHookHandler.php(74): PageImages\Hooks\LinksUpdateHookHandler->getPageImageCandidates(LinksDeletionUpdate)
#6 /srv/mediawiki/php-1.34.0-wmf.6/extensions/PageImages/includes/LinksUpdateHookHandler.php(33): PageImages\Hooks\LinksUpdateHookHandler->doLinksUpdate(LinksDeletionUpdate)
#7 /srv/mediawiki/php-1.34.0-wmf.6/includes/Hooks.php(174): PageImages\Hooks\LinksUpdateHookHandler::onLinksUpdate(LinksDeletionUpdate)
#8 /srv/mediawiki/php-1.34.0-wmf.6/includes/Hooks.php(202): Hooks::callHook(string, array, array, NULL)
#9 /srv/mediawiki/php-1.34.0-wmf.6/includes/deferred/LinksUpdate.php(188): Hooks::run(string, array)
#10 /srv/mediawiki/php-1.34.0-wmf.6/includes/deferred/DeferredUpdates.php(274): LinksUpdate->doUpdate()
#11 /srv/mediawiki/php-1.34.0-wmf.6/includes/deferred/DeferredUpdates.php(219): DeferredUpdates::runUpdate(LinksDeletionUpdate, Wikimedia\Rdbms\LBFactoryMulti, string, integer)
#12 /srv/mediawiki/php-1.34.0-wmf.6/includes/deferred/DeferredUpdates.php(143): DeferredUpdates::execute(array, string, integer)
#13 /srv/mediawiki/php-1.34.0-wmf.6/includes/MediaWiki.php(907): DeferredUpdates::doUpdates(string)
#14 /srv/mediawiki/php-1.34.0-wmf.6/includes/MediaWiki.php(731): MediaWiki->restInPeace(string, boolean)
#15 [internal function]: Closure$MediaWiki::doPostOutputShutdown()

Event Timeline

jijiki created this task.Apr 24 2019, 11:49 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 24 2019, 11:49 AM
jijiki triaged this task as Unbreak Now! priority.Apr 24 2019, 11:51 AM
jijiki updated the task description. (Show Details)
Restricted Application added subscribers: Liuxinyu970226, TerraCodes. · View Herald TranscriptApr 24 2019, 11:51 AM
jijiki updated the task description. (Show Details)Apr 24 2019, 11:52 AM
jijiki added a subscriber: Anomie.
jijiki updated the task description. (Show Details)Apr 24 2019, 1:17 PM
mobrovac lowered the priority of this task from Unbreak Now! to High.Apr 24 2019, 5:34 PM
mobrovac edited subscribers, added: daniel; removed: Anomie.
kchapman assigned this task to Anomie.Apr 26 2019, 3:18 PM
kchapman moved this task from Inbox to MCR on the Core Platform Team board.
kchapman edited projects, added Core Platform Team (MCR); removed Core Platform Team.
kchapman moved this task from Inbox to Next on the Core Platform Team Legacy board.
hashar renamed this task from Unable to move page (Special:MovePage&action=submit) to Unable to move page (Special:MovePage&action=submit) Title does not belong to page ID X but actually belong to Y.May 22 2019, 2:06 PM
Krinkle renamed this task from Unable to move page (Special:MovePage&action=submit) Title does not belong to page ID X but actually belong to Y to Page rename (Special:MovePage) can throw InvalidArgumentException: Title does not belong to page ID X but actually belong to Y..May 30 2019, 12:24 AM
Krinkle edited projects, added PageImages; removed Operations.
Krinkle updated the task description. (Show Details)

Looking through Logstash, it seems all matches for this exception message have a similar stack trace:

  • The request urls are submissions of Special:MovePage (Page rename).
  • The call sites are via PageImages\Hooks\LinksUpdateHookHandler::onLinksUpdate(LinksDeletionUpdate), as fired by the deferred LinksUpdate->doUpdate action.
Krinkle added a comment.EditedMay 30 2019, 11:06 PM

@pmiazga Could your team take a look first to confirm (or rule out) whether PageImages is using Revision::newFromTitle correctly in this context? We can also ask Core Platform to check whether MovePage is issuing the LinksDeletionUpdate incorrectly, but given no other extensions are affected looks like it might be on the PageImages side.

From a quick glance, it is constructing a Revision object by title from a replica db, which seems like it wouldn't be a reliable way to get the wikitext for the edit that just occurred, as it can both be outdated (not yet replicated) or too new (run after other page renames, and thus be updating the wrong title, leaving the one that mattered stay outdated). I would expect LinksUpdate to provide a way to get the correct Content object for your use case, although I don't know off-hand what the right method for that is.

LinksUpdate just has a ParserOutput, with no info about the revision ID or the original Content. It should probably have RenderedRevision, that would solve the problem.

sorry, I missed the ping, I'll look into it today

The LinksUpdate has two methods - setRevision() and getRevision(), the PageImages/LinksUpdateHooksHandler tries to fetch the Revision object via $linksUpdate->getRevision(). If there is no revision, it fallbacks to $rev = Revision::newFromTitle( $linksUpdate->getTitle() ); which is causing this error.

The fallback method was added in T203965: PageImages Maintenance Script finds not all Images, patch rEPIMcd2115f80d78: Reenable Indexing for Images. There is no clear information why LinksUpdate::getRevision() can return null, and using LinksUpdate::getTitle() looked like a correct way to solve that problem. IMHO, the call Revision::newFromTitle( $linksUpdate->getTitle() ) looks like a valid call, we take a Title object, and we ask for revision.

But I think I can understand why it fails, this happens as Deferred action most probably the Page is already renamed (so Title points to different page id), that's why system throws that error.

/cc @daniel @Krinkle

WDoranWMF removed Anomie as the assignee of this task.Jul 17 2019, 8:21 PM
WDoranWMF lowered the priority of this task from High to Normal.
WDoranWMF added a subscriber: Anomie.

In DeferredUpdates.log I saw the following similar error:

2019-07-25 01:21:33 [XTkEHApAIC4AACNzY80AAADA] mw1325 enwiki 1.34.0-wmf.14 DeferredUpdates ERROR: Deferred update LinksDeletionUpdate failed: The given Title does not belong to page ID 61355695 but actually belongs to 44570450 {"type":"LinksDeletionUpdate","message":"The given Title does not belong to page ID 61355695 but actually belongs to 44570450","trace":"#0 /srv/mediawiki/php-1.34.0-wmf.14/includes/Revision/RevisionStore.php(1894): MediaWiki\\Revision\\RevisionStoreRecord->__construct()

I determined that this is reproducible by moving a page over a redirect. The above DeferredUpdates.log entry occurred when I did a test move (move log entry).

I was able to reproduce this locally with PageImages and fake replication (MediaWiki sees two servers but both are really localhost). PageImages calls Revision::newFromTitle() with a Title that has the correct post-move information. RevisionStore fetches the revision information from the slave, retrieving the page and revision row for the redirect that was just deleted. The RevisionStoreRecord constructor does a sanity check, notices the mismatch, and throws an exception. So I think the solution is for PageImages to use the READ_LATEST flag.

Change 525473 had a related patch set uploaded (by Tim Starling; owner: Tim Starling):
[mediawiki/extensions/PageImages@master] Use READ_LATEST during LinksUpdate

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

Change 525473 merged by jenkins-bot:
[mediawiki/extensions/PageImages@master] Use READ_LATEST during LinksUpdate

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

WDoranWMF moved this task from MCR to mop on the Core Platform Team board.Jul 26 2019, 6:38 PM
mmodell changed the subtype of this task from "Task" to "Production Error".Aug 28 2019, 11:07 PM
hashar added a subscriber: hashar.Sep 11 2019, 12:54 PM

One more I have noticed today:

enwikiRevisionStoreRecord.phpThe given Title does not belong to page ID 52943292 but actually belongs to 61713901

One more I have noticed today:

enwikiRevisionStoreRecord.phpThe given Title does not belong to page ID 52943292 but actually belongs to 61713901

Can you provide a stack trace? This issue generally points towards a race condition in the context of renaming or undeletion, but it's impossible to find out what is causing it without a stack trace.

Krinkle removed a subscriber: Krinkle.Tue, Oct 8, 5:14 PM