I was able to review the file with a reviewed edit I made. So the ticket can be closed, I'm just not sure whether you want to keep it open to check the cause or not.

It's still happening in a page in fiwiki: https://logstash.wikimedia.org/goto/59c61188ab8afa294c4b8db12e7cc4c2

What is the fiwiki page? (I don’t have access to Logstash.) The huwiki page has been deleted and undeleted between @Boro's recent edit and the previous one, so I think it suffered from T162778: If reviewed page was deleted and then undeleted, page is marked both as reviewed and unreviewed; maybe it’s the same on fiwiki?

The page is https://fi.wikipedia.org/wiki/Toiminnot:Odottavat_muutokset

That’s a special page, not exactly helpful. ☹ Any chance we can find the actual article? For example using the revision ID included in the message (at least the message in the task description contains it)?

Oh, sorry. Try https://fi.wikipedia.org/w/index.php?oldid=23590538

exception.file = /srv/mediawiki/php-1.45.0-wmf.22/extensions/FlaggedRevs/includes/business/RevisionReviewForm.php:490

exception.message = Flagged revision with ID 23590538 exists with unexpected fr_page_id, error: duplicate review

exception_url = /w/api.php

Looks like this exception happened via the API, via RevisionReviewForm. So the steps to reproduce probably involves using the RevisionReviewForm.

Are there any SQL queries that we can run to see if the database is in a corrupted state for this one page? T162778 seems to me like it could be caused by having weird or contradictory values in the database.

In T402004#11304293, @Novem_Linguae wrote:

Oh, sorry. Try https://fi.wikipedia.org/w/index.php?oldid=23590538

Thanks! This page hasn’t been deleted ever. Maybe here what happened is simply what the end of the error message says, a duplicate review, caused by a race condition?

SELECT fr_timestamp FROM flaggedrevs WHERE fr_rev_id = 23590538;

returns 20251010073231 (2025-10-10 07:32:31). When was the exception logged? (If I understand correctly, the FlaggedRevs backend checks if there is already a review, so the race condition window should be a few milliseconds.)

In T402004#11305068, @Novem_Linguae wrote:

Are there any SQL queries that we can run to see if the database is in a corrupted state for this one page? T162778 seems to me like it could be caused by having weird or contradictory values in the database.

If my theory is correct, and any page deletion/restore causes this, it’s

SELECT fr_page_id, rev_page FROM flaggedrevs JOIN revision ON fr_rev_id = rev_id WHERE fr_rev_id = <revision ID mentioned in the exception>;

and compare the two columns. For huwiki 26797030 it’s indeed different (fr_page_id = 1044748, rev_page = 1993106); for fiwiki 23590538, both columns are 326 (which is why I really wonder if it was just a simple race condition).

By the way, you may try to find all contradictory entries using

SELECT * FROM flaggedrevs JOIN revision ON fr_rev_id = rev_id WHERE fr_page_id <> rev_page;

but it’s slow; I killed it after a few seconds on huwiki. (It did complete in 218 ms on test2wiki, though, yielding five results on three pages: Asia, Strona testowa and 1234.)

I realized that there’s something common in the three test2wiki pages and the huwiki page: they weren’t just deleted and restored, but something more complicated happened: the test2wiki pages were deleted, recreated and then restored (inserting the once-deleted revisions at the end of the revision history), while the huwiki page was split (if I understand the log messages correctly, the logo now visible at Fájl:Magyar Cserkészszövetség logo 2.svg was once uploaded over Fájl:Magyar Cserkészszövetség logo.svg, and then subsequently split out). I guess this is why MediaWiki assigns a new page ID, and FlaggedRevs gets confused by this.

In T402004#11308209, @Tacsipacsi wrote:

SELECT fr_timestamp FROM flaggedrevs WHERE fr_rev_id = 23590538;

returns 20251010073231 (2025-10-10 07:32:31). When was the exception logged? (If I understand correctly, the FlaggedRevs backend checks if there is already a review, so the race condition window should be a few milliseconds.)

Logstash says Oct 10, 2025 @ 07:32:31.457, matching your timestamp.

Also, there is now an additional Logstash entry from plwiki: RevisionReviewForm.php:490. Flagged revision with ID 77883529 exists with unexpected fr_page_id, error: duplicate review

https://pl.wikipedia.org/w/index.php?oldid=77883529

In T402004#11308467, @Novem_Linguae wrote:

Also, there is now an additional Logstash entry from plwiki: RevisionReviewForm.php:490. Flagged revision with ID 77883529 exists with unexpected fr_page_id, error: duplicate review

https://pl.wikipedia.org/w/index.php?oldid=77883529

Which is also a page split.

Actually, why do we have fr_page_id? It can be inferred from fr_rev_id by joining with the revision table (except when things go wrong, like in these cases). As far as I see, the only place where removing the column would need new joins (we query by fr_page_id only, without including fr_rev_id in the condition; and revision isn’t already joined) is the FlaggedRevsStats class – which is run from scheduled jobs (and maintenance scripts) only, so it isn’t very performance-sensitive, nor can it put too much load on the DB servers. (It was added in rSVN20695 without much explanation. Its very first two usages – in that revision – were already such that could have been solved without the new column, by using the existing joins with revision.)

By the way, the same goes for fr_rev_timestamp (which was added in rSVN86179 / rEFLR1bbd5fa1cd681ee0221e45945234476826f142ed).

@Ladsgroup, as someone who knows both FlaggedRevs and DB performance, what do you think about dropping the column?