Page MenuHomePhabricator

Latest revisions should never be tagged as reverted
Closed, ResolvedPublicBUG REPORT

Description

Example: https://cs.wikipedia.org/w/index.php?diff=24717367&uselang=en.

As of now, it is the latest (top) revision of the page, yet it is tagged with "Reverted". By definition, revision followed by no newer revision cannot be reverted.

Possible cause: someone clicked "rollback", but no revision was made because we do not save "dummy" revisions for rollbacks.

Could it be a regression from T386938?

Original report: https://cs.wikipedia.org/wiki/Wikipedie:Pod_l%C3%ADpou_(technika)#c-David_V.-20250304091300-Zna%C4%8Dka_%E2%80%9Erevertov%C3%A1no%E2%80%9C

Related:

Details

Event Timeline

Change #1125640 had a related patch set uploaded (by Matěj Suchánek; author: Matěj Suchánek):

[mediawiki/core@master] Do not enqueue RevertedTagUpdateJob for null edits

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

I found a way to reproduce this:

  1. As user A, make an edit to an existing page
  2. As user A, undo your own edit
  3. As user B, try to rollback user A's edits

This will result in no edit by user B being saved, since there's no change, and tag both of user A's edits as reverted.

The patch fixes this scenario.

Change #1125640 merged by jenkins-bot:

[mediawiki/core@master] Do not enqueue RevertedTagUpdateJob for null edits

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

matmarex assigned this task to matej_suchanek.

The fix will be deployed to Wikimedia wikis next week, on the usual schedule. Thanks @matej_suchanek!

Though now closed, just FYI another issue that may be related but may be fixed in the deployment, we'll see:

https://en.wikipedia.org/w/index.php?title=Wikipedia:Articles_for_deletion/Suicidal-Idol&diff=prev&oldid=1280676318

The next two "edits" after the edit by CFA were page protections, one not an actual edit, and the other one adds the pp-protected padlock, but edit by CFA is marked as "reverted".