For your information, I gave this a quick try, but was not able to reproduce the issue. This does not mean there is no bug, I was just not able to reproduce it yet. I think I followed the instructions given in the task description. Nothing is deleted. Depending on where the other edits (by the 3rd user) are made, clicking save either brings up another edit conflict, or resolves everything just fine. Both is expected behavior.

Possibly related: T246726: Prevent data loss in DiscussionTools caused by MediaWiki not detecting edit conflicts with yourself (also see https://www.mediawiki.org/wiki/Topic:Vhgb6y8dqm58yjni for a discussion about this issue).

We will certainly investigate this further. @Seewolf, can you try to explain how you run into the issue?

Points for investigation of this issue.

Sorry moved wrong ticket ^^'

There are three examples given in the discussions:

• https://de.wikipedia.org/w/index.php?title=Diskussion%3AWirecard&type=revision&diff=201713538&oldid=201706331
• https://de.wikipedia.org/w/index.php?diff=200371492&diffmode=source
• https://de.wikipedia.org/wiki/Special:Diff/201718833/201718902?diffmode=source

There are detailed logs of other conflicts on these pages during July, but nothing is logged for first two examples here. I suggest looking for more clues in the direction of editing directly from the diff view, or other unusual behaviors.

I can find logs for the third example. What we know:

• The conflict was exactly as it appears. The two users started with base revision ID 201718735, an edit 201718833 was made, the conflict was resolved as revision 201718902 .
• The conflict workflow was entered exactly once, but the conflict page was reloaded three times.
• The conflicting user's browser never sent any logs about the workflow. There should have been a corresponding "exit" event for each time the conflict workflow was reopened, but zero were recorded. This might be explained by an adblocker interfering.

In other words, there isn't much I can say about this third example other than, the conflict workflow was entered. Unfortunately, the other detailed log streams I might have been able to use for debugging only date back to August 4th, I've waited too long to investigate this bug.

It's asking a lot, but perhaps the original reporters can try to reproduce this with the adblocker turned off...

Some supporting queries are pasted here,
https://gitlab.com/adamwight/conflict-query/-/blob/b9c5cfa78e76c37869393d32da9d7eb32cbe958d/reports/T257661%20-%20talk%20page%20errors.ipynb