Page MenuHomePhabricator

High proportion of edit conflicts seem to not involve a conflicting edit
Open, MediumPublic

Description

For context, see the description of T246439. We've instrumented edit conflict and in this case, found a large number of conflicts where the page seems to have not been edited during the edit session, so should not have resulted in a conflict. When EditPage reports baseRevisionId equal to latestRevisionId, the article has not advanced while editing.

select
    sum(if(
        event.baseRevisionId == event.latestRevisionId
            and event.baseRevisionId != 0,
        1, 0)) as unedited,
    count(*) as total
from twocolconflictconflict
where
    year=2020 and month=1;

unedited   total
1927       5263

This happens at the same rate with the legacy and new TwoColConflict interfaces, it's coming from EditPage logic.

From reading the code, these are my initial guesses as to the cause:

  • The deprecated edittime parameter can cause a conflict if it was incorrectly set or changed in the edit form.
  • Section replace failure
  • doEditContent return values can trigger a conflict.

Event Timeline

Change 576901 had a related patch set uploaded (by Awight; owner: Awight):
[mediawiki/extensions/TwoColConflict@master] Log debugging information at start of conflicts

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

Change 576901 merged by jenkins-bot:
[mediawiki/extensions/TwoColConflict@master] Log debugging information at start of conflicts

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

WDoranWMF triaged this task as Medium priority.
WDoranWMF raised the priority of this task from Medium to Needs Triage.
WDoranWMF triaged this task as Medium priority.
WDoranWMF added a subscriber: Pchelolo.

Change 596653 had a related patch set uploaded (by Awight; owner: Awight):
[analytics/wmde/TW/edit-conflicts@master] Start investigating same-revision conflicts

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

CCicalese_WMF subscribed.

Is there anything for Platform Engineering to do on this task at this point?

Aklapper added a subscriber: AMooney.

@AMooney: Assuming that "Set projects" was accidentally used instead of "Add projects", hence restoring some previous project tags.

Change 620313 had a related patch set uploaded (by Awight; owner: Awight):
[analytics/wmde/TW/edit-conflicts@master] Filter out two different bugs

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

Change 620314 had a related patch set uploaded (by Awight; owner: Awight):
[analytics/wmde/TW/edit-conflicts@master] [WIP] Report on the conflictless conflict

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

I've refreshed the statistics for this bug, and it accounts for 28.2% of all conflicts experienced. There's good evidence that users are prevented from saving and see the conflict dialog.

@AMooney For comparison, T246439 only appears in 4.3% of conflicts. My guess is that the bugs have the same root cause and should be merged, but until we know that, maybe this bug should be a higher priority?

More confirmation. After querying the Schema:TwoColConflictExit data, I'm even more convinced that all of these users did see a conflict dialog. A small number of the diffs were degenerate, they show a single "copy" block with no changes. But most seem to show a diff between the base revision and the edit just made. In order words, the same thing as "show changes" would have displayed. Users are abandoning this workflow a bit more often than with normal edit conflicts, over half the users abandon. None of this should be happening, though--the page should have been saved in the first place.

Change 620314 abandoned by Awight:
[analytics/wmde/TW/edit-conflicts@master] [WIP] Report on the conflictless conflict

Reason:
squashed

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