Last modified: 2014-08-29 08:26:42 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.
Thanks for bring this to Bugzilla! Issue was also brought up here: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=570511661#Currently_having_an_issue_with_.22edit_conflicts.22 https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=570511661#Edit_conflicts_and_section_editing Link to bug 48429 comment 49 in that discussion provides some background.
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: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574458444#Section_editing 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.
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."
