Topic on Talk:Talk pages project/Replying/Flow

Conflicting edits get reverted

25
Summary last edited by Matma Rex 23:20, 2 March 2020 4 years ago
Thiemo Kreuz (WMDE) (talkcontribs)

I freakin' love the "reply" feature! Every detail of it. The live preview is amazing! The placement of the reply and indention make a lot of sense, in my opinion. More specifically:

  • I'm used to the German Wikipedia convention of ::::: indention, which is what the tool did in my test edits on beta.
  • I can see two possible placements for a reply: Directly under the post I replied to, or at the end of the thread, which is what the feature does right now. I feel the later indeed does make more sense, even if it's different from the convention on German Wikipedia talk pages.

Unfortunately, I experienced a major issue: I tried to mess with the page in another tab, intentionally creating an edit conflict. When I replied in the original tab, my previous edit got reverted without any notice! That should definitely not happen. A reply should never touch anything else on the page, but only insert the reply. If this is not possible, an edit conflict should be triggered.

Ignacio Rodríguez (talkcontribs)

If you check the history of the test page, you will see that even pretty "old" replies got reverted

Whatamidoing (WMF) (talkcontribs)

Thank you for this bug report.

@Matma Rex, could you please make sure that I've linked the correct Phab ticket?

Thiemo Kreuz (WMDE) (talkcontribs)

I don't know the code, but this ticket doesn't sound like it is related. There is nothing about an "edit conflict" or "revert" in this ticket, as far as I can see. If I would need to guess, it looks like the reply feature is calling an API without the base revision ID (or base timestamp) parameter being set.

Matma Rex (talkcontribs)

Yeah, I don't think this is T240519. And we definitely send the base timestamp (as of change 557030, mid-December).

You did not get an edit conflict because you made both actions from the same account, and MediaWiki will never treat that as an edit conflict – it will just override the earlier version with the later one. This is reported as T175745.

If you performed either the edit or the reply using a different account, it would be correctly treated as an edit conflict. In this case, I think MediaWiki's built-in "merging" would resolve it. If that fails, we also have a different approach to conflict resolution in DiscussionTools (change 572399, this was just merged so might not have been in place when you tested yet). And if that also fails, you get an error message about the conflict.

Thiemo Kreuz (WMDE) (talkcontribs)

I'm afraid I don't get how any of this is related. The feature presents itself as if anything it will and can ever do is adding a new paragraph to an existing section. That's all I, as a user of the feature, can see and do: I specify what the new paragraph should contain, and where it will appear. This and nothing else is what I, as a user, expect when I click the button. I might run into a conflict. Ok, fine. But never, under no circumstances ever, should a feature like this revert something, no matter who made the other edit.

It might indeed be that giving such a guarantee is hard, maybe even impossible with the way MediaWiki handles edits. Still I believe you can do better to massively reduce the amount of such unacceptable results. Without knowing the actual code I would suggest to fetch a fresh copy of the paragraph that's going to be edited, find the insert position again (e.g. by finding the previous paragraph, assuming it did not changed), insert my new paragraph, and only then make the edit. Don't forget to send the editRevId along with the edit. This should greatly reduce the chance of bad edits, possibly even eliminating them.

PS: I see the patch gerrit:572399 does something like this, but only does this when the first edit fails. It looks like the first edit is intentionally (?) made based on a revision that is known to be outdated. In other words: Does the code intentionally revert everything, hoping it would run into a conflict? Why should it? If the later edit removes stuff, how should the backend know if this removal was intentional or not?

Matma Rex (talkcontribs)

Thiemo, everything I wrote was to explain the cause of the bug you reported. Please re-read it if you don't see how it's related to your comment ;) I agree with you that the behavior is incorrect, I was just explaining what is causing it.

I don't really understand your last paragraph, so I'm not sure if this will answer your questions, but let me try to explain how the reply posting works anyway. The first edit attempt is based on the most recent revision of the page that existed when you started writing your comment (the "base" revision). Ideally, it would be based on the most recent revision when you try posting (the "latest" revision). But fetching the revisions can be slow for large pages (e.g. village pump), and we must fetch the "base" revision when you start writing anyway to verify that it's possible to reply to that comment, so we try using the same revision for posting the reply as an optimization. This is actually exactly the same as how regular editing of pages works, and the backend resolves the conflict based on the basetimestamp and starttimestamp parameters, like for a normal edit.

Anyway, I wrote that code before I realize that MediaWiki doesn't detect self-conflicts, so maybe we'll need to change it all. But apparently both WMF and WMDE are working on edit conflicts right now, so maybe someone will just resolve T175745.

Matma Rex (talkcontribs)

(I filed T246726 with a summary of the problem.)

Thiemo Kreuz (WMDE) (talkcontribs)
Matma Rex (talkcontribs)

(Task T218460 also describes the same problem, I just found it now.)

Ignacio Rodríguez (talkcontribs)

There were A LOT of revertions that were not made by the same account. Check the test page history! Almost any diff will do. Most will have deletions of previous replies. Many with "red" byte changes.

Whatamidoing (WMF) (talkcontribs)

I set up a two edit conflicts, and both were handled without reverting to an older version.

In the first attempt, I typed two replies (using two different browsers and two separate accounts) and clicked the button to post them within seconds of each other. It auto-resolved the conflict. In my second attempt, I typed a reply in one account, and then edited the section to remove the comment that I was replying to. This gave me an error message. See phab:F31647664 for the error message on my second attempt.

Ignacio Rodríguez (talkcontribs)

It is clear that you guys at WMF don't want to look at the really serious, and in my opinion, blocking issue.

If the tool randomly revert and deletes other users messages, it can't be deployed.

Please check, without biases, just check, this sample of selected diffs, taken from the very test talk page you provided. ALL the diffs have the tag "Reply", so they were made using the new tool.


1) https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Talk:Cats&diff=414541&oldid=414538 MADE by: 90.127.224.201. Deleted several messages by 117.202.204.72, user Andreas, 92.41.51.117, made 5 hours before, even in different parragraphs.

2) https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Talk:Cats&diff=414519&oldid=414518 MADE by 2.207.24.1. Deleted several messages by User Titi, 186.67.71.38, 193.224.131.43, and a WHOLE SECTION of messages, made by IP 186.67.71.38 (myself). All made in the hour before.

3)https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Talk%3ACats&type=revision&diff=414722&oldid=414643 these two replies by 213.127.58.211. Duplicated almost the whole page several times, adding 46k of content.


JUST LOOK

Whatamidoing (WMF) (talkcontribs)

These aren't looking like edit conflicts. Unless it's taking these users multiple hours (five hours for the first) to type a little test message and press return, then I don't think that's the problem.

I have finally managed to duplicate it, and I think it's basically a case of getting what you deserve, when the page has a broken table on it. The visual editor seems to handle it a little more gracefully, so there is probably room for improvement. In practice, I don't expect this to be a problem that editors encounter very often.

Ignacio Rodríguez (talkcontribs)

I thought the WMF was bad, but I didn't thought it was that terrible.


Now volunteers "deserve" to get their messages deleted without notice, because of some faulty code.

It took me literally one minute searching in the history to find

https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Talk%3ACats&type=revision&diff=414481&oldid=414480 this diff, MADE by 91.65.183.96. Deleted several messages by 151.64.101.0, User:Ppelberg-test, User:Shizhao, and 185.229.4.5. Before any "broken table" was introduced in the page.


In practice, I don't expect this to be a problem at all. It can't happen not even once, not without noticing the user.

Jc86035 (talkcontribs)

@Ninovolador, do you think this issue is limited to the beta cluster, or do you think it would be possible to replicate it on one of the wikis where DiscussionTools can currently be used?

Ignacio Rodríguez (talkcontribs)

I can't possibly know that. Maybe the only way to know will be to actually deploy it.

Jc86035 (talkcontribs)

In case you weren't aware, it is already possible to use DiscussionTools on the Dutch, French, Arabic and Hungarian Wikipedias by appending the parameter ?dtenable=1 to the page URL (e.g. https://fr.wikipedia.org/wiki/Discussion_utilisateur:Exemple?dtenable=1). I would suggest creating a subpage of your user talk page in one of those Wikipedias to use as a test page.

Whatamidoing (WMF) (talkcontribs)

The Beta Cluster can be subject to strange behaviors. What they will need, though, is a method for reproducing this bug. I can do something like it by putting a broken wikitable on the page. I can't reproduce it through edit conflicts or through editing old versions of the page. If we can't reproduce it now, it may have already been fixed. If it's not fixed, but we can't reproduce it, then there is no way for the devs to know whether their changes have actually fixed it.

Ignacio Rodríguez (talkcontribs)
Ignacio Rodríguez (talkcontribs)
Matma Rex (talkcontribs)

@Ninovolador I have explained in my comment here a few days ago (#flow-post-vhjieu1h0uityns0 – hm, can you even link to Flow posts like that?) that edits by the same user are not subject to edit conflict detection in MediaWiki, and therefore you can accidentally overwrite your earlier edits. This is a poor behavior, and it would be nice to avoid this, but you can only lose your own comments in this way and only if you were posting on the same page simultaneously in multiple browser tabs.

I think your other examples were not caused by edit conflicts per se, but rather by adding a reply while viewing an old revision from the page history. This incorrect behavior is already fixed (T235761). All of your examples are edits from February 24 or earlier, which is when this was fixed.

If there are any situations where we cause data loss, where the edits were made after February 24, and there are at least two users involved, please let us know.

Matma Rex (talkcontribs)

(I filed T246726 with a summary of the problem, and I promise we're going to work on it soon.)

Matma Rex (talkcontribs)
Thiemo Kreuz (WMDE) (talkcontribs)

I tried to repeat my experiment, and it looks much better now! Awesome! \o/

Reply to "Conflicting edits get reverted"