Page MenuHomeMiraheze
Create Task
Maniphest T5943

Problem with Previously Manually Patrolled Revisions Now Unpatrolled across WIkis
Closed, InvalidPublic
Actions

Description

Problem: This problem appears to be related, but in different ways, to the Phabricator task/issue reports identified in the below section (T5939 / T5940). Earlier this morning, there were a series of errors related to the job queue/redis-server (see T5939), and one of the problems reported in those logs, @RhinosF1 noted, was related to Special:RecentChanges. When the immediate problem was fixed and the redis-server restarted by @Paladox, all, or most, of the revisions requiring patrolling (i.e., those of non-administrators and non-autopatrolled users) now again required patrolling even though they had been previously patrolled by different patrolling users or administrators. I've only gone back to June 18th on the community noticeboard on Meta to manually repatrol, to see if I can see how far back this goes.

Reproducable? Yes, @RhinosF1 and @AmandaCath have also repatrolled some of the revisions that had been previously manually patrolled, which, in addition to my repatrolling, provides the needed confirmation and verification of the problem.

Commentary: In commentary on the #irc-relay channel on Discord, @RhinosF1 asked @Paladox about parsing the error logs, removing the duplicate wikis, and utilizing "rebuildAll" to resolve any pending jobs in the queue. @Paladox initially replied that that would take "weeks," then corrected and said "a month or two." So, as best as I can tell, they worked together to focus on the most pressing issues and rebuilt them in batches. Nevertheless, these unpatrolled revisions are problematic for ongoing patrolling of current revisions, so something needs to be done

Possible Solutions:

  1. Re-analyze and re-assess @Paladox's time assessment for running rebuildAll, to see if rebuildAll could be done in a few hours or less;
  2. Manually repair the database in some way to mark all unpatrolled revisions prior to ~6:13 AM (presumably UTC?) as patrolled across all wikis. Any revisions that shouldn't have needed patrolling will be manually corrected by local wiki administrators; or,
  3. Something else.

Related reported bugs/issues:

  1. T5939
  2. T5940

System Information:
Vivaldi 3.1.1929.45 (Stable channel) (64-bit)
Revision 1eb3263017ed42270818939fbff241845938a81f
OS Windows 10 OS Version 1909 (Build 18363.959)
JavaScript V8 8.3.110.13
Flash 32.0.0.387 C:\WINDOWS\system32\Macromed\Flash\pepflashplayer64_32_0_0_387.dll
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.119 Safari/537.36
Command Line "C:\Users\Wylie\AppData\Local\Vivaldi\Application\vivaldi.exe" --flag-switches-begin --flag-switches-end --enable-audio-service-sandbox --ppapi-flash-path="C:\WINDOWS\system32\Macromed\Flash\pepflashplayer64_32_0_0_387.dll" --save-page-as-mhtml
Executable Path C:\Users\Wylie\AppData\Local\Vivaldi\Application\vivaldi.exe
Profile Path C:\Users\Wylie\AppData\Local\Vivaldi\User Data\Default

Related Objects

Event Timeline

Dmehus triaged this task as High priority.Jul 20 2020, 17:33
Dmehus created this task.
Herald added subscribers: Void, Reception123, NDKilla. · View Herald TranscriptJul 20 2020, 17:33
Dmehus updated the task description. (Show Details)Jul 20 2020, 17:34
Dmehus updated the task description. (Show Details)Jul 20 2020, 17:36
Dmehus updated the task description. (Show Details)
Dmehus updated the task description. (Show Details)
RhinosF1 added a comment.Jul 20 2020, 17:38

We ran rebuildrecentchanges and refreshLinks instead on all wikis affected by the redis failure. Rebuild all shouldn't make a difference.

Is it just meta affected?

Dmehus added a comment.Jul 20 2020, 17:54

Replying to @RhinosF1's question on Phabricator, to update everyone here of our Discord conversation...I'm going to manually check a handful of the wikis affected to see if it affects more than just Meta. Just need @Paladox to re-open Paste P332.

AmandaCath moved this task from Backlog to Bugs on the MediaWiki board.Jul 20 2020, 18:05
Sario528 subscribed.Jul 20 2020, 20:38
John removed a project: Production Error.Jul 21 2020, 08:40
Void added a comment.Jul 21 2020, 13:26

This is a side effect of running rebuildrecentchanges.php and will affect any wiki the script is ran on. Running rebuildall.php won't make a difference, because it runs the same exact thing.

RhinosF1 added a comment.EditedJul 21 2020, 15:52

The only thing I can think is to mass mark previous revisions as patrolled on affected wikis and to complain upstream about it. The script is supposed to just refresh RecentChanges rather than wipe actual data.

Reception123 lowered the priority of this task from High to Normal.Jul 22 2020, 06:06
Dmehus added a comment.Jul 24 2020, 05:45

@RhinosF1 Yeah, it's probably my second choice, but I'd support us mass marking all unpatrolled revisions on the affected wikis up to the point of the redis-server incident as patrolled. It's better than leaving them unpatrolled, and no one wants to manually repatrol years worth of old revisions.

John closed this task as Invalid.Jul 30 2020, 15:31
John subscribed.

Specific requests should be made for wikis if they want all revisions to be automatically patrolled.

Dmehus reopened this task as Open.Jul 30 2020, 20:14

@John, since this was related to a reported system incident, I think we should still try and resolve this. @RhinosF1 had another idea, aside from my idea to manually patrol all revisions to a specific date, that was discussed on Discord, but can't remember the gist of the idea. Could we explore that idea, or, failing that, run either a seven day community discussion on the community noticeboard or a thirty day RfC to build community support for doing this?

John closed this task as Invalid.Jul 30 2020, 20:28

Still marking as invalid per my original rationale. This would take seconds to do by anyone who wanted to do so as a sysadmin - however I'm not seeing any specific request for action from anyone affected by this issue.

This was causes by a common maintenance script that is ran, and is something we've done since 2015 and have never had a request to manually patrol all revisions.

Therefore my advice is - if this is a problem, open a task for a specific wiki and it can be resolved. A generic task for this is undefined, highlights something we know and doesn't provide any grounds for resolution.

Dmehus added a comment.EditedJul 30 2020, 20:40

@John Well, many Mirahezians don't really understand how patrolled revisions even work, so they likely aren't aware this is even a problem. They may not even be patrolling revisions.

My concern is on Meta. Can we at least do this on Meta, or do I need to start a seven day discussion on the community noticeboard on Meta?

Edit: Looking through the older revisions on Meta, there doesn't seem to have been any previously patrolled revisions from prior to January 2020 that have become unpatrolled. So, it would just be the previously patrolled revisions, now unpatrolled as a result of the redis-server/jobrunner issue, that need to be manually patrolled in a batch, to ease the huge backlog created in Special:NewPages and Special:RecentChanges

RhinosF1 added a comment.Jul 30 2020, 20:54

I can just do a mass mark for meta when at my pc. I'm happy to do that as based on my local authority.

Dmehus added a comment.Jul 31 2020, 01:43

@RhinosF1 Okay, thanks for volunteering. Are you just going to write a quick script to mass patrol the revisions within the given time parameters (on Meta)?

Should we also maybe send some sort of notification to the affected wikis from that incident report (those that actively patrol their revisions in the first place), and make them aware of the issue, so they can independently decide whether to request for a correction of their previously patrolled revisions?

Dmehus mentioned this in T6392: Problem with Previously Manually Patrolled Revisions Now Unpatrolled on TestWiki.Nov 2 2020, 00:55