Page MenuHomePhabricator

Better handle edit conflicts (race conditions) in DiscussionTools
Closed, ResolvedPublic

Description

Steps to reproduce:

  1. Open the same talk page open on two windows, one logged in and one not logged in, in an incognito window
  1. On both tabs, draft a reply to the same comment.
  1. Hit the reply button one after another. (I know this is not an exact simulation of true race condition, but the timestamp shown was the same, so I considered it as a race condition. I can try doing it at the same time too if that's more helpful to figure out the exact test result).
  1. After clicking on the reply button, on both tabs it was showing their own replies correctly, but after a refresh it seemed it discarded one of the replies and kept the one from the anonymous user.

Test Environment: Beta cluster

Event Timeline

We see behavior similar to this on-wiki today on occasion, where one person's edit obliterates someone who made a comment just before (and occasionally it is a longer time period--I think that is usually due to users who start an edit long before and then come back to finish it after someone else as made a comment in the same space, which for some reason the edit conflicter won't catch). I can't point to any diffs offhand.

I suppose this tool might make that case more common.

Ryasmeen renamed this task from One of the replies get lost during a race condition to One of the replies gets lost during a race condition .Dec 13 2019, 6:48 AM
matmarex subscribed.

I think this problem is simpler, edit conflict detection just doesn't work at all.

Change 557030 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/DiscussionTools@master] Correct typos to fix edit conflict detection

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

Change 557030 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Correct typos to fix edit conflict detection

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

@matmarex: has this fix landed on Beta yet? Because, I am noticing that, when one of the repliers posts a comment, the other person now just simply cannot post any comment, clicking on "Reply" button does nothing. And this behavior is different from yesterday, where both were able to post a reply to a comment at the same time but one of them was getting lost.

I think it landed, and that would be the expected behavior right now, given that we haven't written any error handling yet. That's tracked on T240519 (and after it's done, you'll simply get a message saying "Edit conflict." in this situation, we'll need to do more work to handle this nicer).

I think it is also not possible to edit conflict with yourself, you have to test with two accounts (or one logged out).

I think it is also not possible to edit conflict with yourself, you have to test with two accounts (or one logged out).

Yeah, that's how I found this issue. I guess @matmarex's comment confirms that there is nothing more to be tested for this task. I will check the error handling once T240519 is fixed. Moving this to PM review.

Before resolving, I'd like to confirm the following is true:

DiscussionTools will handle errors in the same way VE currently does. See: T240519.


Context: T235923#5863149

It is mostly true – it's true for everything except edit conflicts, where VE has a custom interface to "redirect" you to the old edit form, while DiscussionTools has nothing (you just get an error message that says "Edit conflict.").

I think we can handle edit conflicts better than that (as long as the comment you're replying to hasn't been deleted, we should be able to find it in the latest revision of the page, and insert the reply there).

I'll rephrase this task to be about handling that. I want to work on this soon.

matmarex renamed this task from One of the replies gets lost during a race condition to Better handle edit conflicts (race conditions) in DiscussionTools.Feb 11 2020, 4:16 PM
matmarex claimed this task.

It is mostly true – it's true for everything except edit conflicts, where VE has a custom interface to "redirect" you to the old edit form, while DiscussionTools has nothing (you just get an error message that says "Edit conflict.").

Understood – thank you for explaining.

I think we can handle edit conflicts better than that (as long as the comment you're replying to hasn't been deleted, we should be able to find it in the latest revision of the page, and insert the reply there).

I'll rephrase this task to be about handling that. I want to work on this soon.

Sounds good. In the meantime, I'm going to adjust the edit tags to reflect this plan.

Change 572399 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/DiscussionTools@master] Try to resolve edit conflicts

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

Change 572399 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Try to resolve edit conflicts

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

Is this change the one responsible for this error message? Or just for the ability to reply to the same comment simultaneously?

Screen shot 2020-02-27 DiscussionTools Reply edit conflict.png (1×1 px, 220 KB)

Yes, I added it in this change as well.

ok so the two changes that I observed after the last merged patch are:

  1. When two accounts (or one logged in and one anonymous account) adds reply to the same comment:
  • Both are able to post their comments
  • No comments get discarded
  • The comments get posted in the order they were posted.
  1. When someone tries to reply to a deleted comment they get the following error message:

Screen Shot 2020-03-04 at 3.58.21 PM.png (339×1 px, 74 KB)

They seem expected to me. Moving it to Sign off.