Hello @ssr. Why is this task assigned to @Bawolff ? Did you asked him, and he agreed to work on this task? That he resolved T234715 doesn't mean he will be working on this one too, although he can of course choose to do so :) Regards.

In T237408#5636824, @MarcoAurelio wrote:

Hello @ssr. Why is this task assigned to @Bawolff ? Did you asked him, and he agreed to work on this task? That he resolved T234715 doesn't mean he will be working on this one too, although he can of course choose to do so :) Regards.

Hello! He is the one who showed most competence in previous task and seems to me as a specialist in "flagged revisions". Because of language barriers, we wasted some time previously before finding out that he was the most suitable person for this topic. And yes he asked me to open more tickets, so I mentioned him now instantly. Of course I am not insisting on his presence and task may be re-assigned to anyone more suitable.

For what it's worth, I do intend to look into this.

Change 548951 had a related patch set uploaded (by Brian Wolff; owner: Brian Wolff):
[mediawiki/extensions/FlaggedRevs@master] Fix cache invalidation in stableVersionIsSynced()

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

In T237408#5639059, @gerritbot wrote:

Change 548951 had a related patch set uploaded (by Brian Wolff; owner: Brian Wolff):
[mediawiki/extensions/FlaggedRevs@master] Fix cache invalidation in stableVersionIsSynced()

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

So I'm not sure if this fully fixes the issue. I think it definitely fixes part of the issue.

So in your description this will definitely fix step 4 & maybe step 3. I don't actually understand why the banner goes away after step 6. Its possible that there are further race conditions involved in step 3. But in any case, this patch once merged should definitely improve the situation a lot - so I guess we'll just have to test after its merged and see if there's more problems, or if this fixes it.

Change 548953 had a related patch set uploaded (by Reedy; owner: Brian Wolff):
[mediawiki/extensions/FlaggedRevs@REL1_34] Fix cache invalidation in stableVersionIsSynced()

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

Change 548953 merged by jenkins-bot:
[mediawiki/extensions/FlaggedRevs@REL1_34] Fix cache invalidation in stableVersionIsSynced()

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

Change 548951 merged by jenkins-bot:
[mediawiki/extensions/FlaggedRevs@master] Fix cache invalidation in stableVersionIsSynced()

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

@Bawolff Thank you developers for helping us. This particular issue, which I opened, now seems to be resolved, but not right after the abovementioned patch, but some time later.

Let me describe the important problem that we have. It is related to this issue, but rather a tweak than a bug. It was difficult for me to make the PNGs, so I try to write by text. If I have to open new request, please ask, and I will. The text:

Russian Wikinews want unmoderated comments (verb "patrol" below means "flagged review")

1. There are the "Comments" namespace in Russian Wikinews. It reads "Комментарии:". It is different from "Talk" namespace which reads "Обсуждение:". "Комментарии:" name space is attached only to main articles and not elsewhere, e. g. forums. At each article, link "Комментарии:" a) is attached at the upper tab as a 3rd namespace link b) is transcluded below the article by a custom bot operated by @Krassotkin. Transclusion template contains instructions for commenters and invites all people to comment their thoughts on the subject of the news story. This is very different from "Talk:" ("Обсуждение:") which is meant for editors to discuss story writing process not its subject and is not transcluded in this way.

2. When a visitor wants to comment, they are given "Комментарии:" namespace page in editing mode. They comment and save.

3. The whole main article becomes "unpatrolled" (un-flagged-reviewed). As result, the visitor cannot view their own comment that they just have written. This is confusing.

4. Only after an "editor"-flagged regular Wikinews author presses "partol" (flagged review) on the main article, visitor can see its own comment and maintain further talk. If several visitors try to talk to each other, they are unable to talk in real-time: each edit have to be "patrolled" (flag-rev'd). If any "flagged reviewers" are not available at the time, hours and days may pass.

In fact, this is an unintended pre-moderation of comments that is against democratic journalistic free-speech principles that we believe in.

The task: cancel this pre-moderation. Adjust the flagging review system in the way when visitors can talk real-time.

Hmm, $wgFlaggedRevsHandleIncludes looks to be 2 for ruwikinews, and Комментарии (ns 102) is not in $wgFlaggedNamespaces. Reading the docs:

"2 - (FR_INCLUDES_STABLE)",
"  For each template/file, check if a version of it was used when the page was reviewed and if the template/file itself has a stable version; use the newest those versions",
"NOTE: We may have templates that do not have stable version. Also, given situational inclusion of templates (e.g. parser functions selecting template X or Y based on date) there may also be no \"review time version\" revision ID for a template used on a page. In such cases, we select the current (unreviewed) revision. Likewise for files."

So since Комментарии: can't be reviewed, the docs seem to suggest the most recent version should be selected, which is what @ssr wants. So i guess there is a bug in flaggedrevs somewhere.