I see all the groups I should be seeing (["checkuser", "sysop", "*", "user", "autoconfirmed"]).

The error message says The action you have requested is limited to users in one of the groups: Editors, Reviewers.
What it should say (and does if I load the page in incognito mode) is Administrators, Editors. So this does seem like an issue with site configuration being messed up occasionally.

Bumping priority - while the flagrev issue is not so severe, we don't know if anything else is affected, and if configuration is not loaded consistently, there is potential for worse fallout.

To the best of my knowledge en-wiki doesn't use FlaggedRevs extension (as a replacement for the native patrol mechanics). Compare

• https://en.wikipedia.org/wiki/Special:ReviewedPages ("No such special page")
• https://ru.wikipedia.org/wiki/Special:ReviewedPages (list of pages)

This way either the problem caused by come recent core patrolling bug or these are two very different bugs (like say this one and T234121) with similar end effects.

As the patrolling mechanics of two (at least) major wiki projects is currently completely crewed (to avoid stronger expressions) - I would suggest to raise this bug priority.

Update: oops, did not notice it is already High, sorry.

In T233561#5537071, @Neolexx wrote:

To the best of my knowledge en-wiki doesn't use FlaggedRevs extension (as a replacement for the native patrol mechanics). Compare

In enwiki it is named as "Pending changes" and in flagged revision configuration name is "protection setup" which means that only small subset of the pages are in FlaggedRevs review loop and it is used for protecting the pages.

• https://en.wikipedia.org/wiki/Wikipedia:Pending_changes

Traditional setup like in dewiki, ruwiki, huwiki, fiwiki etc is that whole namespace is included.

Review (FlaggedRevs) log for ISS: https://en.wikipedia.org/wiki/Special:Log?type=review&user=&page=International+Space+Station&wpdate=&tagfilter=&subtype=
Patrol (core) log: https://en.wikipedia.org/wiki/Special:Log?type=patrol&user=&page=International+Space+Station&wpdate=&tagfilter=&subtype=

Same for the other article in the task description - these are definitely FLaggedRevs-related issues.

In T233561#5537079, @Zache wrote:

In enwiki it is named as "Pending changes" and in flagged revision configuration name is "protection setup" which means that only small subset of the pages are in FlaggedRevs review loop.

Ah, OK.
The current FlaggedRevs usage is highly twisty and very far from what the extension has been written years ago. At least at ru-wiki.
Basically when someone "patrolling" a page, she sets its quality criterion "accuracy" from 0 to 1. There are 3 criteria (accuracy, depth, tone) and 4 levels for each (0, 1, 2, 3) - but it all has been blocked ages ago as not used.
And an added level of logic interprets accuracy==1 as patrolled, accuracy==0 as unpatrolled,
It seems that with some recent changes the system got some kind of A.I. so started to sort out edits to 1) not affecting "accuracy" and 2) affecting "accuracy". Or started to set "accuracy" higher than 1. So expecting user rights no lesser than reviewer. And there are close to none of such users because this side of the project is long time ago abandonned (ru-wiki has maybe 20 of them kept for historical purposes).

Just brainstorming, don't get upset if gibberish.

I tried to check yesterday if the patrolling is working or not too, but there are not many wikis where wgUseRCPatrol and FlaggedRews are both enabled. Also when revision is manually reviewed then it will be patrolled too which will mask the problem.

In de.wiktionary.org there was edit by user with autoreview and autopatrol user rights which was still autopatrolled but not autoreviewed.

• https://de.wiktionary.org/w/index.php?title=geldi&oldid=6070691&diff=7237740

select rc_id, rc_title, rc_cur_id, rc_this_oldid, fp_stable, rc_timestamp, rc_patrolled, fr_rev_id FROM flaggedpages, recentchanges LEFT JOIN flaggedrevs ON fr_rev_id=rc_this_oldid WHERE rc_cur_id=fp_page_id AND rc_this_oldid = 7237740;

However the result of my investigation was that even if it looks like that patrolling worked here we cannot know it using the available information.

In T233561#5537181, @Zache wrote:

In de.wiktionary.org there was edit by user with autoreview and autopatrol user rights which was still autopatrolled but not autoreviewed.

• https://de.wiktionary.org/w/index.php?title=geldi&oldid=6070691&diff=7237740

Nothing seems out of the ordinary there:

08:54, 17 September 2019 Peter Gröbner talk contribs block reviewed a version of geldi (changes reviewed) (revision: 13:52, 30 June 2017)
08:54, 17 September 2019 Peter Gröbner talk contribs block deprecated a version of geldi (changes deprecated) (revision: 08:53, 17 September 2019)
08:53, 17 September 2019 Peter Gröbner talk contribs block deprecated a version of geldi (revision: 13:52, 30 June 2017)
08:53, 17 September 2019 Peter Gröbner talk contribs block automatically reviewed a version of geldi (changes reviewed) (revision: 08:53, 17 September 2019)

In general autoreviews are hard to verify since you have to reconstruct the review state at the time of the edit. Eg. an edit might not get autoreviewed because the parent revision was not reviewed, and then the parent revision might get reviewed later...

Long time ago just for fun I wrote a patrolling script that works straight through the wrapping interfaces: https://ru.wikipedia.org/wiki/User:Neolexx/review.js

So it literally sets article's "accuracy" criterion to 1 or 0, which is reflected in the top interface as patrolled or not. So (tested) in normal circumstances it was not matter to use the script or to press conventional patrol button in the web-interface.

Now it could worth to see this script results on different edits, if fails and where.

And - in continuation of my first mad idea that the engine somehow got a mind of its own - to check ORES scores of edits. To see if there is any connection between edits' scores and their autopatrol failures.

In T233561#5537057, @Tgr wrote:

I see all the groups I should be seeing (["checkuser", "sysop", "*", "user", "autoconfirmed"]).

The error message says The action you have requested is limited to users in one of the groups: Editors, Reviewers.
What it should say (and does if I load the page in incognito mode) is Administrators, Editors. So this does seem like an issue with site configuration being messed up occasionally.

"The action you have requested is limited to users in one of the groups: Editors, Reviewers" would happen if wmf-config/flaggedrevs.php configuration for huwiki is not loaded. (this is FR default groups for unreviewedpages)

Also, my guess is that if the file wmf-config/flaggedrevs.php is not loaded at all then data expected by default wgFlaggedRevsTags settings is different compared to previous revision with huwiki settings in db so it would not do an autoreview because that. This is however guessing.

I also saw this on enwiki (protection configuration) on September 23. As a sysop, it told me that I could not accept a pending change. After a hard refresh, I was able to accept it.

In T233561#5537361, @Tgr wrote:

In general autoreviews are hard to verify since you have to reconstruct the review state at the time of the edit. Eg. an edit might not get autoreviewed because the parent revision was not reviewed, and then the parent revision might get reviewed later...

To be honest, I am in the project since 2008 and patroller since 2011 - but the patrolling part remains beyond my intellectual capabilities. I just know what to do (say patrol the article after removing DR request which is autopatrolled and the like). But what do I do (in the logical sense) - I still don't know.

Any way and leaving the theoretical questions behind - the engine allows to have articles which are 1) not patrolled but 2) having patrolled edits in them in any random order, including the latest edit.

From the other side FlaggedRevs by design is a "whole thing" so applies to the entire article (entire revision version). No one planned to review and set quality levels of accuracy, depth or tone of a separate edit while disregarding the article state in whole. If FlaggedRevs later has been learned to act in patrol-like way - then it is a hack (or OK - added feature). And then at some point all this set of added features just stopped to work.

I do agree that we need more show cases. And actual (unfixed) show cases, because looking in the page history and event journals doesn't help too much. Same with test-wiki - only an actual project with full set of added features may help. The topic is discussed at ru-wiki techforum, I may propose there to allocate a set of guinea pig articles. Something what is not too painful to temporary screw up in the name of science. If goes and new actual samples - I link it here.

To all discussion participants: don't listen Neolexx. This user can't understand Flagged Revs mechanics, makes false statements about it, confuses himself and others. Two years ago all ruwiki's technically competent users in the amount of more than five people were trying to explain him simple FR mechanics, but failed. Don't listen him and his false statements, for example about "engine allows to have articles which are not patrolled but having patrolled last edit" (this statement is clearly wrong).

In T233561#5540276, @MBH wrote:

Don't listen him and his false statements, for example about "engine allows to have articles which are not patrolled but having patrolled last edit" (this statement is clearly wrong).

It is funny to read clearly wrong statement with a "clearly wrong" comment about the right statement. But we should excuse MBH as he's one of ru-wiki users with reviewer rights (left for historical purposes, 26 users in total). So his "patrolling" interface and mechanics differs to others but it is easy to forget.

Also if there is any behind logic in this bug and it is connected with FlaggedRews features - then the bug should never happen with edits of users from the group reviewer If they are sometimes affected as well the the situation even more mysterious.

Of course, this bug should never happen for users with "reviewer" rights, 'cause it happens only for users with "autoeditor" right, not "editor" and not "reviewer".

As so far there are very few of "of course" things in it. Let's us take fact that "patrolling" is just an imaginary thing existing only as a social contract and nothing else.
The only real thing is "reviewing" the whole page (not a given edit) accuracy for its states "not acceptable" (0) and "acceptable" (1). And any "patroller" has right to set it to 0 or 1 - but only reviewer may set it to 2, 3 or 1001. So now what may happen if reviewer "patrolled" a page as accuracy==2 and some other "patroller" made an edit after that? Technically it is a request to change the "accuracy" criterion level beyond the allowance (0 or 1) - so the refusal. Just keep brainstorming, don't get too upset.

In T233561#5540891, @Neolexx wrote:

but only reviewer may set it to 2, 3 or 1001.

OK, purely technically wrong, even reviewer cannot set it higher than 2(?) The point is that the underlying engine recognizes only zero accuracy state ("not patrolled") and non-zero accuracy state ("patrolled"). And anything else falls under the current editor rights and so we come.

Fresh to whatever UTC-related time (you figure out) problematic article states: https://ru.wikipedia.org/wiki/Википедия:Форум/Технический#samples01

In general, please follow the Phabricator etiquette: "Criticize ideas, not people." Thanks for keeping discussions respectful and without getting personal here.

I got an idea of what may happen. If I'm right then all problematic articles have been once "patrollled" by setting their "quality" to 0 like
https://ru.wikipedia.org/w/api.php?format=xmlfm&action=query&list=reviewedpages&rpnamespace=0&rpfilterlevel=0&rplimit=1&rpstart=884521
or
https://ru.wikipedia.org/w/api.php?format=xmlfm&action=query&list=reviewedpages&rpnamespace=0&rpfilterlevel=0&rplimit=1&rpstart=5325503

If not and there ara also problems with "quality" 1 - then I'm wrong and no use to go into details.

FlaggedRevs currently doesn't have a clear maintainer (T185664) making things even more complicated.

Since Sep.23 (this bag open by en-wiki user) it seems that there is not any progress. At ru-wiki Землеройкин summed up some facts: "Кратко суммирую факты" ("Summing up some facts").

IMHO more properly would be to say not facts (like some definitely proven things) but like educated guesses made by observing a large set of affected articles: https://ru.wikipedia.org/wiki/Википедия:Форум/Технический#samples01
The majority of them for the moment of this post left unfixed for the purpose of further testing if needed. So the facts are (and we remember that FlaggedRevs installation and usage is different between ru-wiki and en-wiki):

• So far no bug case of the kind found prior September 19
• September 19 is when MediaWiki 1.34/wmf.23 has been deployed. But the only change related to FlaggedRevs was this one (function () { changed to function () use ( $fname ) {) and hardly has anything to do with the problem.
• The problem still persists affecting approx. 5% of examined pages with pending changes.
• The problem affects only autopatrolled users (автопатрулируемый). Who has reviewing rights - they are not affected.
• The problem happens with 1) page edit, 2) new page creation, 3) page renaming
• There is not any visible system or logic. Just all suddenly the actions of the same used - that should be autopatrolled - stop being autopatrolled. Sometimes just a few seconds after the previous normally processed action. Some samples from the list above:
  • https://ru.wikipedia.org/w/api.php?format=xmlfm&action=query&prop=revisions&titles=Хут,%20Малич%20Салихович&rvlimit=max&rvprop=ids|timestamp|user|flagged
  • https://ru.wikipedia.org/w/api.php?format=xmlfm&action=query&prop=revisions&titles=Иберы&rvlimit=max&rvprop=ids|timestamp|user|flagged
  • https://ru.wikipedia.org/w/api.php?format=xmlfm&action=query&prop=revisions&titles=Та%20Лу,%20Мари-Жозе&rvlimit=max&rvprop=ids|timestamp|user|flagged

That's all for now.

In T233561#5544804, @Neolexx wrote:

I got an idea of what may happen.

That idea appeared to be plain wrong.
As a round #2 :-) - illogical and random character of the problem reminds me T224491 Which is marked as fixed but maybe that PHP 7 quirk came back here? So sometimes some edit context gets corrupted by one char (say "review" becomes "reviev" or something)?

@DannyS712 @Tgr @Zache I wrote a bot that reviews all edit sequences that was not reviewed due to this bug. I wrote it for ruwiki, but if you want, I can launch it for your wikis too, if your wikis grant "editor" flag to my bot.

In T233561#5570753, @MBH wrote:

@DannyS712 @Tgr @Zache I wrote a bot that reviews all edit sequences that was not reviewed due to this bug. I wrote it for ruwiki, but if you want, I can launch it for your wikis too, if your wikis grant "editor" flag to my bot.

Thank you for your offer. However, in fiwiki SeulojaBot does this already as part of it's approval workflow.

In T233561#5570753, @MBH wrote:

@DannyS712 @Tgr @Zache I wrote a bot that reviews all edit sequences that was not reviewed due to this bug. I wrote it for ruwiki, but if you want, I can launch it for your wikis too, if your wikis grant "editor" flag to my bot.

Is the source code public?

https://tools.wmflabs.org/mbh/patrol.txt (C#)
Code is dirty, but working.

In T233561#5570781, @MBH wrote:

https://tools.wmflabs.org/mbh/patrol.txt (C#)
Code is dirty, but working.

Question: the resulting API call seems to just be written to the console; is there no validation to ensure the call was a success?
It should be pretty easy to get approval, although you will need to localize the summary message. Also, on WMF wikis using [[phab:T233561]] as the link should work instead of the full hyperlink, and it is generally (imo) clearer

I updated code (https://tools.wmflabs.org/mbh/patrol.txt, use Ctrl-F5). Now API answer is written to the console only if call was unsuccessful, error message contains page title and API answer. Of course, a message will be localized.

See [1] as an example of bot's action.

[1]: https://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%96%D1%83%D1%80%D0%BD%D0%B0%D0%BB%D1%8B?type=review&user=MBHbot&page=%D0%97%D0%B0%D1%80%D0%B5%D1%87%D1%8C%D0%B5+%28%D0%BC%D1%83%D0%BD%D0%B8%D1%86%D0%B8%D0%BF%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5+%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5+%D0%B3%D0%BE%D1%80%D0%BE%D0%B4+%D0%95%D1%84%D1%80%D0%B5%D0%BC%D0%BE%D0%B2%29&wpdate=&tagfilter=&subtype=

Other phenomena in huwiki not mentioned by this time:

• the "undo" link is randomly missing
• the Accept revision, Reject changes buttons, comment field and the whole box around them are missing.

In my experience reloading the page always helps.

Just a thought: for me it seems like the beginning of the problems in time may be close to the beginning of frequent HTTP 503 server errors. I can't prove it, this is just an idea. May there be any connection?

The problem still persists at ru-wiki, MBH had to write a bot so once a day to patrol unpatrolled pages after autopatrollers' edits, Which is sounding just like it looks like (=~ wtf)
To avoid terms mishmash: ru-wiki uses FlaggedRevs as its top layer patrolling mechanics. So any further "patrol", "patrolling" means "actions as it is reflected over FlaggedRevs interfaces". If about native tools, then "old patrol", "old patrolling" (as they named in the web-interface).

So:

• only autopatrollers are affected, not patrollers = allowed to patrol someone else edits
• it is about 1% to 4% of autopatrollers' edits
• no system (time, previous edits frequency etc.) found so far

As a continuous brainstorming there are two ideas there the help of WMF developers would be needed.
https://ru.wikipedia.org/wiki/Википедия:Форум/Технический#Ещё_одна_идея

1. PHP7

During the beta-testing such random edit forwards were marked by "php7". Now the beta-testing is over, the tag is marked as not active and not used https://ru.wikipedia.org/wiki/Служебная:Метки
Yet is any testing still in progress? If so - is it possible to check if failed cases correlate to the random PHP7 forwards? Because purely statistically it fits rather well.

2. config files

wmf-config/flaggedrevs.php has both autopatrollers and patrollers (API name - autoeditor and editor)
wmf-config/InitialiseSettings.php has only patrollers (API name - editor). It also has some "autoreviewer" groups - but such group doesn't exist.
So if wmf-config/flaggedrevs.php somehow fails to load - the system gets a patrol request from a user of a unknown group - so declines it.

So it could help to somehow write all group aliases right into wmf-config/InitialiseSettings.php
It doesn't solve the problem 1) but it might solve the ending problem with autopatrol.

Another failure: Some users are automatically checked that shouldn't be: https://en.wikinews.org/w/index.php?title=Wikinews_discusses_International_Women%27s_Day_celebration_with_Mysore_Divisional_Railway_Manager&action=history - wikinews doesn't have any users that are autochecked, so there should be no "automatically checked" in the history

https://en.wikipedia.org/w/index.php?title=Tor_(anonymity_network)&oldid=951928262&diff=cur&diffonly=0&diffmode=source is another example of the original problem I just suffered. It should have been auto accepted but wasn’t.

Does this still exist or was this solved too when [[phab:T237191]] was fixed? (by https://gerrit.wikimedia.org/r/627332)

In T233561#6657357, @Zache wrote:

Does this still exist or was this solved too when [[phab:T237191]] was fixed? (by https://gerrit.wikimedia.org/r/627332)

Seems to have been solved.

Actually not least by T237191 as Tgr noted in second ticket.

In T234743#6657474, @Tgr wrote:

This is caused by $wgGroupPermissions being incorrect and that patch only touched $wgFlaggedRevsAutopromote / $wgFlaggedRevsAutoconfirm so probably not.

It seems that this bug is still present. Please see the complaints on enwiki at this thread and this village pump thread. I personally encountered this issue when reviewing this pending change. The user that submitted the change was autoconfirmed and therefore should have had their edit automatically accepted, as there were no pending edits before them.

My most recent edit wasn't automatically accepted. According to Special:ListGroupRights, my rights should include autoreview and movestable but they are missing from https://en.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=* - are these rights usually in the list there?

I made enough edits with my alternative account to be autoconfirmed but these rights were not added. There is also a permission error when moving pages with pending changes enabled: "You do not have permission to move this page, for the following reason: You are not allowed to execute the action you have requested."

As noted in the parent task (T234743#7063693), this might be fixed now. Your help with re-testing it would be appreciated!

I haven’t seen reports about this in the past months. Is it because editors got tired of reporting it, or is it really fixed?

In T233561#7610797, @Tacsipacsi wrote:

I haven’t seen reports about this in the past months. Is it because editors got tired of reporting it, or is it really fixed?

The underlying code bug is not fixed, but there is a mitigation in place on the English Wikipedia: a bot has been approved to automatically accept pending changes where they should have been automatically accepted by the software. You can see the bot's review log actions here: https://en.wikipedia.org/wiki/Special:Log?type=review&user=FireflyBot+II

As you can see, the issue is still occurring as of January 7, 2022.

Has anyone seen this bug lately? I talked to the FireflyBot II maintainer, and he says the bug seems to have gone away, which explains why his bot hasn't edited since May 31, 2022.

If no one has seen the bug lately, we can probably close this ticket.

My bot did the same in ruwiki and the problem gone on March 30, 2021, see https://ru.wikipedia.org/w/index.php?title=special:log&type=review&user=MBHbot&offset=&limit=500

Odd that MBHbot has a stopping point (2021-06-02 and 2022-11-05 2021-03-30) that is very different from FireflyBot II (2022-05-31). One would expect a patch that fixed this bug to have them all stop on the same date.

You could use Google Translate to understand what my bot did on 2021-06-02. This is not connected with this bug. 2022-11-05 too.

Ghost in the machine! MBHBot stopped a month before rOMWC9722a37ca149: flaggedrevs.php: Use MediaWikiServices, not an extension function was deployed (I could see that patch fixing the issue). No idea what's up with that.

FireflyBot II stopped roughly around the SettingsBuilder rewrite (T300129: SettingsBuilder: replace DefaultSettings.php). I'm not familiar enough with that change to know if it might have been the reason and which of the many commits would be the relevant one, but since this issue is somehow related to site settings not loading correctly, it seems like a plausible cause.

Anyway, we can close this is as resolved then?