Page MenuHomePhabricator

Investigation: edit conflict for (almost) concurrently save-operations on the same entity
Closed, ResolvedPublic

Description

Users are seeing edit conflicts when editing several parts of the fingerprint or sitelinks in one go.


Version: master
Severity: major
Whiteboard: u=dev c=backend p=0

Details

Reference
bz71555

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 3:56 AM
bzimport set Reference to bz71555.
bzimport added a subscriber: Unknown Object (MLST).
  • Bug 71518 has been marked as a duplicate of this bug. ***

Ok, tried this on wikidata.beta.wmflabs.org.
I tried to change 3 labels in 3 different languages (de, es, and nds) at once, which resulted in three requests sent at pretty much the same time:

  1. action=wbsetlabel&format=json&id=Q32119&value=label1&language=de&baserevid=59739
  2. action=wbsetlabel&format=json&id=Q32119&value=label2&language=es&baserevid=59739
  3. action=wbsetlabel&format=json&id=Q32119&value=label3&language=nds&baserevid=59739

Note that the baserevid is the same for all three requests. This is supposed to cause an edit-conflict if I would change a label in the same language twice but it should definitely not cause an edit conflict when editing labels in different languages. I would guess there is a bug in the patching mechanism not taking the different language into account.

Investigated a bit more. It seems the problem only occurs if the requests are sent nearly at the same time. If you wait a few milliseconds between the requests it works fine. Reproduced this with two different users on wikidata.beta.wmflabs.org. User1 changed the de label while User2 changed the en label at the same time. If they click on save at the same time they get an edit conflict. If User2 waits a short moment there's no edit conflict.

Wouldn't it be better if only one request was sent? When clicking on save I don't suppose several edits are made but only one.

Yes, but that doesn't solve the case of multiple user outlined in comment #3 .

We do want several edits to be able to have granular, translatable edit summaries.

(In reply to Jan Zerebecki from comment #5)

Yes, but that doesn't solve the case of multiple user outlined in comment #3
.

The case that two different users hit save in the same second is very rare and perhaps not really fixable at all. However, this happens now very often because we send several requests when hitting save once. Also when several edits are made only one request should be sent imo to avoid those issues.

(In reply to Bene* from comment #7)

(In reply to Jan Zerebecki from comment #5)

Yes, but that doesn't solve the case of multiple user outlined in comment #3
.

The case that two different users hit save in the same second is very rare
and perhaps not really fixable at all. However, this happens now very often
because we send several requests when hitting save once. Also when several
edits are made only one request should be sent imo to avoid those issues.

Something would be really wrong if this is not fixable.
Having one request for multiple edits would solve the issue with the multi-edit-mode but introduce another one. As Lydia already outlined, the changes made would not be granular on history and recent changes pages anymore. You would just see: "Item Q1234 was changed". It is simply not possible to pack all the possible information about a possibly huge edit into 256 chars of summary (which is a limit in MediaWiki).

Changed the topic of the bug:
This does not only happen when editing several terms or sitelinks at the same time. This applies to any edit operation on an entity. When several save-operations happen at the same time an edit-conflict is detected. This needs investigation what the root-cause is.

Some symptoms of this might be worked around by https://bugzilla.wikimedia.org/show_bug.cgi?id=72020 but the root-cause really lies in the backend and must be solved separately.

I guess this is a "late" edit conflict which happens after the attempted edit conflict resolution (patching). Possible solutions might include re-attempting to patch the entity in case we hit a late conflict. Not sure how much work that would be.

Lydia_Pintscher removed a subscriber: Unknown Object (MLST).
Lydia_Pintscher removed a subscriber: Unknown Object (MLST).Dec 1 2014, 2:33 PM

Yes, likely, but it needs to be tested if this was really the cause.

hoo claimed this task.

Haven't personally seen this in a while, although changing a lot of terms at once. Assuming fixed.

@hoo That's probably because the UI queues edits. We would want to remove that queuing for terms and sitelinks if the issue in the back-end indeed is solved. Can you double-check? cc @Jonas.