Last modified: 2014-08-29 08:26:42 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T55446, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 53446 - Edit conflicts for editing different sections on popular article
Edit conflicts for editing different sections on popular article
Status: NEW
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: 70163
  Show dependency treegraph
Reported: 2013-08-28 01:54 UTC by SlimVirgin
Modified: 2014-08-29 08:26 UTC (History)
7 users (show)

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


Description SlimVirgin 2013-08-28 01:54:16 UTC
I'm not familiar with how to report bugs, so apologies if I'm doing anything wrong. For the last few days we've had high traffic and lots of edit conflicts on enwiki at [[en:Talk:Chelsea Manning]]. Section editing is not preventing edit conflicts. After multiple edit conflicts, the history shows that each editor was posting to a different section. It is making talk-page interaction very difficult.
Comment 2 parsecboy 2013-09-25 13:32:08 UTC
This doesn't seem to be limited to high traffic pages, as I have experienced it recently with only one other editor on a relatively low-traffic talk page. See my comment here:

I have also experienced the problem on articles where I am the only person editing them (i.e., editing different sections in multiple browsers, like adding a {{reflist}} template to the ref section in the middle of rewriting another so the footnotes appear correctly upon saving both), though I can't seem to track down any specific diffs at the moment.
Comment 3 C. Scott Ananian 2013-09-28 00:48:39 UTC
On the page linked in comment 2, Wikid77 says, "Overwrite of 1-minute edits has been problem for months or years: Several other users have noted similar problems, sometimes imagining the next editor has deliberately deleted their recent comment, where the prior edit was auto-erased when saving the next edit, within 1 minute after the prior edit. I think it is the "age-old" problem of needing to read-lock the database entry (the page) so that, before an edit can be saved, all other pending edits must wait to only re-read the page after the prior edit has been saved (only 1 session could read the prior revision at a time during the SAVE), then do a diff against the latest read-locked page and auto-merge with the latest prior save, as to not auto-merge by both edits reading the same version of 2 revisions prior as being the revision to merge. Again, unless each SAVE does an exclusive (rapid) read+write lock of the page, then 2 quick edits of a page will both try to merge changes into the same old revision, rather than sequentially readlocking to update once (then unlock), so the 2nd edit is forced to read only after the first edit is saved, to ensure updating the next latest revision in sequence, not merge with 2 revisions back. Note that the exclusive read+write lock would only apply to delay edit-save transactions, and article viewing would not be delayed by the read-lock option. The typical test-and-set logic is needed to control a semaphore to ensure how 2 edits within 1 minute must sequentially wait to read the results of the prior edit-save, before merging new changes, as a 3rd revision applied to the 2nd revision."

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