I'm still investigating, and likely have misinterpreted the few clues. As part of Two-Column-Edit-Conflict-Merge, we instrumented the EditPageBeforeConflictDiff hook to record some information about the conflict, for both the legacy and newer TwoColConflict conflict workflows.
The event fields include,
- $baseRevision = $editPage->getBaseRevision();
- $latestRevision = $editPage->getArticle()->getRevision();
In other words, $baseRevision was the latest revision of the article at the time the edit page was opened, and $latestRevision is the latest revision at the time the edit page is submitted.
What we discovered is that roughly 1/3 of the edit conflicts have $baseRevision = $latestRevision = 0, which means that the article is new, no saved revision exists. This is happening at equal rates for both the legacy and new conflict interface, so it's caused by EditPage logic. Querying the Hive event database,
select
sum(if(event.baseRevisionId == 0, 1, 0)) as new,
count(*) as total
from twocolconflictconflict
where
year=2020 and month=1;
new total
1399 5263From a superficial reading of EditPage, my only guess is that doEditContent has failed with one of these error codes: edit-gone-missing, edit-conflict, or edit-already-exists.