Last modified: 2010-05-15 15:38:17 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 2626 - Clicking rollback more than once after timeout produces multiple reverts
Clicking rollback more than once after timeout produces multiple reverts
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
1.5.x
PC Windows XP
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/w/index.php?t...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-30 04:54 UTC by Gregory Phillips
Modified: 2010-05-15 15:38 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Gregory Phillips 2005-06-30 04:54:37 UTC
Overview Description:

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.

Actual Results:

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.

Expected Results:

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
Comment 1 Aaron Schulz 2008-03-24 19:27:07 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links