Was fixed in T361940: Imports, moves and protections are not autoreviewed and is now broken again.

Unable to reproduce on localhost using plwiki settings and an admin account (which has autoreview). The steps to reproduce may be a bit more complicated than shown in the ticket. Any ideas on how to improve the steps to reproduce?

Renaming without a redirect definitely produces an unpatrolled page 100% of the time; can you check that?

Good idea, but also didn't work for me in localhost.

Try to rename any page on a live ruwiki (see merged task).

Here's screen recording of me reproducing the bug on plwiki: (I was doing it in Help: namespace but it's not significant for the problem)

I faced the same problem on huwiki. See: https://hu.wikipedia.org/w/index.php?title=Port%C3%A1l:Wikip%C3%A9dia/Jel%C3%B6lt_lapv%C3%A1ltozatok/Test2&action=history&uselang=en

10:50 edit didn't get Reverted tag. https://hu.wikipedia.org/w/index.php?title=Moszkva&date-range-to=2024-07-03&tagfilter=&action=history&uselang=en

Hi, The bug is related to git a2989af2, I reverted and bug was solved for Patch Demo.

In T368380#9948984, @Gerges wrote:

Hi, The bug is related to git a2989af2, I reverted and bug was solved for Patch Demo.

I don't see how that patch could have caused the issue described here, since it's not yet live on huwiki or plwiki.
That change was only morged on July 1, it is being rolled out with this week's train - it's in the 1.43.0-wmf.12 branch, which hasn't hit group 2 yet (it will tomorrow, if the train stays on schedule). But right now, https://pl.wikipedia.org/wiki/Specjalna:Wersja still has 1.43.0-wmf.11.

Can you reproduce the issue in Patch Demo on 1.43.0-wmf.11?

Based on timing, this patch is a more likely culprit: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/1047111. Though I wouldn't have expecte it to go live on the relevant wikis before June 27, while the bug was reported on June 25.

Another option would be https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/1043047

None of these seems problematic in an obvious way, but who knows.

@daniel, I have no idea, I found this issue on arwiki and found this as an open ticket so I reported what I knew.

I'm also confused.

If this is API-related, it'd help to know what the request and response actually look like (including request body). If it is convenient, could someone reproduce the issue and post the relevant information from their browser developer tools?

If that's not convenient, I can set up FlaggedRevs locally and do it, but it'd be next week.

Auto-reviews should not involve the web API at all, right?...

They shouldn’t. Which also means ruling out d8c86b1238b3e4e300356140d36a70051599eb7b (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/1047111). (By the way, the timing also rules it out: it landed with wmf.11 – the bug was first reported on Tuesday, June 25, but wmf.11 reached group2 wikis like plwiki only on Thursday, June 27 (T366956#9931834).)

The only non-localization update patch in wmf/1.43.0-wmf.9..wmf/1.43.0-wmf.10 is b4c528fe2d9e59f319a112e93f9d3cd3c1c7d2fd (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/1043047). There are three possibilities:

• b4c528fe2d9e59f319a112e93f9d3cd3c1c7d2fd is the culprit.
• A change in core (or another extension) is the culprit.
• The bug is older, but no one noticed it earlier.

I've browsed through the move log at plwiki and the issue started appearing between Wed, 2024-06-19 19:39 UTC (the last move that was automatically reviewed) and Thu, 2024-06-20 09:11 UTC (the first move that wasn't auto-reviewed but should be).

wmf.10 was indeed deployed in this timeslot (at 08:16 UTC according to T361404#9908513)

FWIW, I tried to reproduce this locally, but without success. That indicates that it's not an obvious bug in FlaggedRevs, but some subtle interaction, possibly with caching, possibly with something else.

Tagging MediaWiki-Engineering for triage

In T368380#9953124, @Msz2001 wrote:

I've browsed through the move log at plwiki and the issue started appearing between Wed, 2024-06-19 19:39 UTC (the last move that was automatically reviewed) and Thu, 2024-06-20 09:11 UTC (the first move that wasn't auto-reviewed but should be).

wmf.10 was indeed deployed in this timeslot (at 08:16 UTC according to T361404#9908513)

Indeed, the dewiki logs give an even more accurate approximation, which confirms this: autoreviewed move at 07:22 UTC (09:22 CEST), non-autoreviewed move by autochecked user at 08:19 UTC (10:19 CEST).

In T368380#9953144, @daniel wrote:

FWIW, I tried to reproduce this locally, but without success. That indicates that it's not an obvious bug in FlaggedRevs, but some subtle interaction, possibly with caching, possibly with something else.

Maybe another extension aborts a hook FlaggedRevs depends on?

We could try writing a page move integration test. If it passes in localhost and fails in CI (which loads a ton of extensions), that would support the hypothesis of another extension interfering with something in FlaggedRevs.

Change #1052142 had a related patch set uploaded (by Novem Linguae; author: Novem Linguae):

[mediawiki/extensions/FlaggedRevs@master] tests: add page move test

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

OK, I wrote a page move integration test (see patch above). It passes in both my localhost and CI 🤷‍♂️

In T368380#9955001, @Novem_Linguae wrote:

OK, I wrote a page move integration test (see patch above). It passes in both my localhost and CI 🤷‍♂️

We don't run tests for all the extensions in CI...

But it could be related to something else, like some complex combination of permissions. Or caching.

Change #1052142 merged by jenkins-bot:

[mediawiki/extensions/FlaggedRevs@master] tests: add page move test

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

On wikisource we move quite often pages with several subpages (move subpages). It is a very convenient semi-batch mode. The bug is most disturbing...

Maybe it should be test on Parsoid? Do we need $poutput stuff during autoreview?

In T368380#9954488, @Tacsipacsi wrote:

Maybe another extension aborts a hook FlaggedRevs depends on?

At a quick skim I don't see any PageMoveComplete hook handler in Wikimedia production that would ever return false.

In T368380#9982475, @Tgr wrote:

In T368380#9954488, @Tacsipacsi wrote:

Maybe another extension aborts a hook FlaggedRevs depends on?

At a quick skim I don't see any PageMoveComplete hook handler in Wikimedia production that would ever return false.

RevisionFromEditComplete is also called during moving.

This is a really annoying bug when you have to do a lot of renames because then the redirects and the renamed pages need reviewing. Maybe we should test it in Patchdemo instead of locally? Or is it not close enough, too?

Is the issue reproducible in Beta? If not, I think the path of least resistance is to book a deploy session, add some logging on one of the production debug hosts, and check via X-Wikimedia-Debug whether 1) the hook handler actually executes, 2) if not, which hook handlers execute and which don't, 3) if yes, just dump a lot of information inside the hook and hope to spot what's going wrong.

Locally, I am unable to reproduce this issue. Is there any update?

In T368380#10183841, @Eugene wrote:

Locally, I am unable to reproduce this issue.

It was unreproduceable locally from the beginning (T368380#9937740) but still persists on production.

To be precise: edits after (inclusive) page move are unrevieved. All edits before retain status. Redirect is autoreviewed, even after T379218.

You can test on de.wikipedia.beta.wmflabs.org

New info.
If bot reviews these edits, they are marked as... autoreviewed instead of reviewed by <username>.

Examples here: https://pl.wikipedia.org/wiki/Dyskusja_wikipedysty:MszBot/Przegl%C4%85danie_stron#Rejestr

If anyone is interested in that, I've created a bot to automatically review moved and created pages (this is the bot that Wargo talks about above). It works in real time, based on EventStreams, so as to make an impression that this issue is no longer present. (Review log from plwiki).

I can run it on other wikis as well if the community is interested.

Change #1088672 had a related patch set uploaded (by Wargo; author: Wargo):

[mediawiki/extensions/FlaggedRevs@master] Use RevisionRecord provided by onPageMoveComplete

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

Unfortunately, fix to T379218: New pages are not autoreviewed despite creator having autoreview right doesn't fix this issue, so moved pages still become unreviewed.

I still can't reproduce this locally.

Has anyone successfully reproduced this on beta cluster? If so, maybe we can try merging https://gerrit.wikimedia.org/r/1088672 and seeing if that patch fixes this.

In T368380#10311364, @Novem_Linguae wrote:

Has anyone successfully reproduced this on beta cluster?

On Beta Cluster this problem also appears. But not on wikis non-prepared to be on Wikimedia (Patchdemo, private wikis...).

https://de.wikipedia.beta.wmflabs.org/w/index.php?title=Flaggedrevs-202411/move/try2/2&action=history

Change #1088672 merged by jenkins-bot:

[mediawiki/extensions/FlaggedRevs@master] Use RevisionRecord provided by onPageMoveComplete

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