Can reproduce

One curios thing I forgot to mention: The "review" link on the "pending changes" page doesn't even link to the right page, but to Hnutie za demokraciu, which is a redirect to the page.

And this redirect page has the page ID 2784562 mentioned in the above Stack Trace...

Did someone change anything? Editing as IP was possible, and now I can even edit the page when logged in. But reviewing still doesn't work.

And editing still doesn't work when "review last changes" is checked

I looked a bit through the code, the wrong page ID comes from this db query in FlaggedRevision::newFromStable().
When I got this right, it takes the page entry from the 'flaggedpages' table and joins the revision given by the 'fp_stable' field. And the wrong page ID is the one from the revision table.
So I would say, that it is most possibly a faulty 'fp_stable' entry, that could cause this behaviour.

Another page with same issue: Andreas M. Fleckner

The given Title (Andreas M. Fleckner) does not belong to page ID 11184614 but actually belongs to 11184613

The wrong page ID belongs to Andreas Martin Fleckner.
Again it's a redirect to the page, but in this case it was created by moving the page.

Looks like I was right with the faulty 'fp_stable' in the 'flaggedpages' db table:

According to the API the stable rev of Bewegung für Demokratie is '34817869', but that's in fact the first rev of Hnutie za demokraciu

And for Andreas M. Fleckner the API shows '197328679', which points to Andreas Martin Fleckner.

In T246720#5938796, @Wickie37 wrote:

Looks like I was right with the faulty 'fp_stable' in the 'flaggedpages' db table:

Yes, and the fp_stable values should be unique least in the cases where both pages exists. However, I don't know how it handles the cases where page is deleted and then undeleted.

In T246720#5940537, @Zache wrote:

In T246720#5938796, @Wickie37 wrote:

Looks like I was right with the faulty 'fp_stable' in the 'flaggedpages' db table:

Yes, and the fp_stable values should be unique least in the cases where both pages exists. However, I don't know how it handles the cases where page is deleted and then undeleted.

But at least in the first case there is no delete/undelete in the logs. So that's not the issue.

The common denominator of the two known cases in deWP is, that the wrong stable rev id belongs to a page that is a redirect to the page it is falsely associated to. But I don't know how redirects work on the software level.

The cases on deWP are know fixed by temporary moving the pages to a non-review namespace (which deletes the wrong db entries) and moving them back afterwards.

But this is only a workaround and we still don't know what caused the wrong entries in the first place.

May be related:

• T204793: Flow TopicPageCreationListener causes "InvalidArgumentException: The given Title does not belong" from MutableRevisionRecord.php
• T221763: LinksUpdate fails during page move due to "Title does not belong to page" RevisionStore error from PageImages hook
• T225366: "Fatal exception: MediaWiki\Revision\InvalidArgumentException" when trying to move user JS page on en.wp

New case on dewp: https://quarry.wmflabs.org/query/42941
Must have happened in the last two days, because editing and reviewing the page still worked then: https://de.wikipedia.org/wiki/Spezial:Logbuch?type=&user=&page=Bell+Food&wpdate=&tagfilter=&wpfilters%5B%5D=review

@Wickie37 can you update the priority for this task?

The same problems occured at trying to move Matthias Henkel, Junioren-Orientierungslauf-Weltmeisterschaften 2011, Junioren-Orientierungslauf-Weltmeisterschaften 2012 and Merchawia in dewiki. Problem can be solved by moving without redirect.

Change 587722 had a related patch set uploaded (by Daniel Kinzler; owner: Daniel Kinzler):
[mediawiki/core@master] RevisionStore and PageUpdater: handle stale page ID

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

The fact that this problem appears to persist confuses me.

I can see the article ID in the Title object getting out of whack during a page move. But that should only happen within the same request, or maybe in jobs triggered by that request. I don't really see how certain pages hit this inconsistency repeatedly. Unless FlaggedRevs stores the wrong page ID...

In T246720#5938728, @Wickie37 wrote:

Another page with same issue: Andreas M. Fleckner

The given Title (Andreas M. Fleckner) does not belong to page ID 11184614 but actually belongs to 11184613

The wrong page ID belongs to Andreas Martin Fleckner.
Again it's a redirect to the page, but in this case it was created by moving the page.

Basically, the Title object still has the old page ID,

The patch I submitted will fix failures that are due to stale local Title objects during moves. It will probably not fix persistent inconsistencies.

I found some entries in the flaggedrevs with a fr_page_id value different from the rev_page value in the corresponding revision row. So far, I have only found instances in which fr_page_id did not exist in the page table. I suspect the page was deleted, and later restored with the same revision IDs but a new page ID. These days we also restore the page ID if possible, but we didn't always do that, and still sometimes don't.

Example:

MariaDB [iswiktionary_p]> select fr_rev_id, rev_id, fr_page_id, rev_page
from flaggedrevs join revision on rev_id = fr_rev_id
where  rev_page != fr_page_id 
group by fr_page_id limit 10;
+-----------+--------+------------+----------+
| fr_rev_id | rev_id | fr_page_id | rev_page |
+-----------+--------+------------+----------+
|    155704 | 155704 |      26023 |    37660 |
+-----------+--------+------------+----------+

This kind of inconsistency looks suspicious, but I can edit the page without problems. Maybe the error would be triggered if my edits would get auto-reviewed?

In T246720#5953183, @Wickie37 wrote:

The cases on deWP are know fixed by temporary moving the pages to a non-review namespace (which deletes the wrong db entries) and moving them back afterwards.

Unfortunately, the fix makes it impossible to investigate the problem in the database now...

In T246720#5938796, @Wickie37 wrote:

Looks like I was right with the faulty 'fp_stable' in the 'flaggedpages' db table:

According to the API the stable rev of Bewegung für Demokratie is '34817869', but that's in fact the first rev of Hnutie za demokraciu

That's a very nice catch. I'm currently trying to find more instance of this using this query:

select fp_page_id, fr_page_id, fr_rev_id
from flaggedpages
join flaggedrevs on fp_stable = fr_rev_id
where fp_page_id != fr_page_id 
and exists ( select * from page where page_id = fp_page_id )
limit 20;

However, the query is quite slow. I'm still waiting for it to return on fiwiki, which doesn't have all that many rows in flaggedpages.

Change 587849 had a related patch set uploaded (by Daniel Kinzler; owner: Daniel Kinzler):
[mediawiki/extensions/FlaggedRevs@master] FaggedRevision: handle mismatching page ID.

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

I'm seeing the same exception and start of the trace from JobQueue as well. I'll track it here for now but feel free to split if it turns out to be a separate/similar issue.

The same issue is also causing RefreshLinks jobs to be aborted in JobQueue execution. This means category members, file usage tracking, WhatLinksHere, search etc is likely outdated or absent for the pages that triggered this error.

 The given Title … does not belong to page ID 7408765 but actually belongs to 7348192
#0 /srv/mediawiki/php-1.35.0-wmf.27/includes/Revision/RevisionStore.php(1471): MediaWiki\Revision\RevisionStoreRecord->__construct(Title, User, CommentStoreComment, stdClass, MediaWiki\Revision\RevisionSlots, boolean)
#1 /srv/mediawiki/php-1.35.0-wmf.27/includes/Revision/RevisionStore.php(1394): MediaWiki\Revision\RevisionStore->newRevisionFromRowAndSlots(stdClass, MediaWiki\Revision\RevisionSlots, integer, Title, boolean)
#2 /srv/mediawiki/php-1.35.0-wmf.27/includes/Revision.php(377): MediaWiki\Revision\RevisionStore->newRevisionFromRow(stdClass, integer, Title)
#3 /srv/mediawiki/php-1.35.0-wmf.27/extensions/FlaggedRevs/backend/FlaggedRevision.php(77): Revision->__construct(stdClass, integer, Title)
#4 /srv/mediawiki/php-1.35.0-wmf.27/extensions/FlaggedRevs/backend/FlaggedRevision.php(193): FlaggedRevision->__construct(stdClass, Title, integer)
#5 /srv/mediawiki/php-1.35.0-wmf.27/extensions/FlaggedRevs/backend/FlaggedRevs.php(658): FlaggedRevision::newFromStable(Title, integer)
#6 /srv/mediawiki/php-1.35.0-wmf.27/extensions/FlaggedRevs/backend/FRStableVersionUpdate.php(35): FlaggedRevs::stableVersionUpdates(Title, NULL, NULL, MediaWiki\Revision\RenderedRevision)
#7 /srv/mediawiki/php-1.35.0-wmf.27/includes/deferred/DeferredUpdates.php(417): FRStableVersionUpdate->doUpdate()
#8 /srv/mediawiki/php-1.35.0-wmf.27/includes/deferred/RefreshSecondaryDataUpdate.php(97): DeferredUpdates::attemptUpdate(FRStableVersionUpdate, Wikimedia\Rdbms\LBFactoryMulti)
#9 /srv/mediawiki/php-1.35.0-wmf.27/includes/deferred/DeferredUpdates.php(417): RefreshSecondaryDataUpdate->doUpdate()
#10 /srv/mediawiki/php-1.35.0-wmf.27/includes/Storage/DerivedPageDataUpdater.php(1641): DeferredUpdates::attemptUpdate(RefreshSecondaryDataUpdate, Wikimedia\Rdbms\LBFactoryMulti)
#11 /srv/mediawiki/php-1.35.0-wmf.27/includes/page/WikiPage.php(2143): MediaWiki\Storage\DerivedPageDataUpdater->doSecondaryDataUpdates(array)
#12 /srv/mediawiki/php-1.35.0-wmf.27/includes/jobqueue/jobs/RefreshLinksJob.php(190): WikiPage->doSecondaryDataUpdates(array)
#13 /srv/mediawiki/php-1.35.0-wmf.27/includes/jobqueue/jobs/RefreshLinksJob.php(126): RefreshLinksJob->runForTitle(Title)
#14 /srv/mediawiki/php-1.35.0-wmf.27/extensions/EventBus/includes/JobExecutor.php(71): RefreshLinksJob->run()
#15 /srv/mediawiki/rpc/RunSingleJob.php(76): JobExecutor->execute(array)
#16 {main}

In T246720#6062980, @Krinkle wrote:

If being unable to edit some pages on Wikipedia isn't UBN, I don't know what is.

In ranked, descending order:

1. Reading any page.
2. Reverting vandalism visible to users.
3. Deleting any page.
4. Editing any page.
5. Editing many pages.

Results for arwiki:

MariaDB [arwiki_p]> select fp_page_id, fr_page_id, fr_rev_id
    -> from flaggedpages
    -> join flaggedrevs on fp_stable = fr_rev_id
    -> where fp_page_id != fr_page_id 
    -> and exists ( select * from page where page_id = fp_page_id )
    -> limit 20;
+------------+------------+-----------+
| fp_page_id | fr_page_id | fr_rev_id |
+------------+------------+-----------+
|     462708 |    7396178 |  45706021 |
|     543886 |    7317887 |  44932118 |
|    5546359 |    7295302 |  43567327 |
|    7103918 |    7103929 |  42070295 |
|    7348192 |    7408765 |  45800568 |
+------------+------------+-----------+
5 rows in set (8 min 31.05 sec)

Change 587722 merged by jenkins-bot:
[mediawiki/core@master] RevisionStore and PageUpdater: handle stale page ID

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

Change 587849 merged by jenkins-bot:
[mediawiki/extensions/FlaggedRevs@master] FlaggedRevision: handle mismatching page ID.

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

I the fix live? Because there is a new case on dewp:

https://de.wikipedia.org/wiki/Friedrich_Wilhelm_von_Schadow

Latest version is reviewed according to log, but page is indicated as not reviewed. Try to re-review fails with error "The given Title (Friedrich Wilhelm von Schadow) does not belong to page ID 1685060 but actually belongs to 185539".

Edit: Ok found it myself, the fix will be deployed tomorrow.