Last modified: 2010-05-15 15:38:17 UTC
After a clicked rollback (on a diff page) seems to time out (1-2+ minutes without a
response), and despite checking the history (in a different window) to see that the
rollback did not register, reloading the diff page (in the same new window) and
clicking rollback again produces multiple reverts in the article history, which seem
to duplicate themselves.
Steps to Reproduce (attempts to reproduce failed, so here is a structured rundown of
what led to it):
1) Load diff from RC in a new window, click rollback.
2) After waiting for the rollback to register for 1-2 minutes, open target article's
history in a new window, to see if the revert has gone through. This obviously
requires lag, which is unpredictable.
3) After confirming that the rollback did not go through, load the current diff from
the history page and click rollback again.
4) Rinse and repeat, using the "rollback" links already available in the two
windows. I actually only did the re-clicking twice, for a total of three rollbacks.
Once the server finally responds to the rollback requests, each window will load a
page with the title "Action complete" and the body text "Reverted edits by X to last
version by X" in large point. Revisiting the history shows that all three reverts
went through, separated by as much as two minutes. Additionally, each revert seems
to be either duplicated or quadruplicated, resulting in ten consecutive reverts of
the same target edit. These reverts also appear in user contribs. The article text
itself was not duplicated.
Only the first successful revert should have registered, and all other attempts
should have returned a "Rollback failed" page with the explanation that the last
editor was not the one you were trying to revert. Attempts to duplicate this bug
with quick, simultaneous rollbacks of the same edit from different windows returned
the expected failure message, but in these cases no lag was observed.
Build Date & Platform:
? - This happened on en.wikipedia.org, 2005-06-30
Haven't seen this happen again, and inspection shows that rollback code (at least now) is reading from the master, so this shouldn't happen.