Last modified: 2014-08-29 08:26:42 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T36580, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 34580 - Prepending or appending text should not throw edit conflicts (action=edit) when basetimestamp is not provided
Prepending or appending text should not throw edit conflicts (action=edit) wh...
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
unspecified
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 70163 62995
  Show dependency treegraph
 
Reported: 2012-02-22 00:06 UTC by Rainer Rillke @commons.wikimedia
Modified: 2014-08-29 08:26 UTC (History)
12 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Rainer Rillke @commons.wikimedia 2012-02-22 00:06:02 UTC
Sorry, I didn't know against which component I should have filed this bug. The API is just an interface but I don't know how "the database works". I think the API could be smart and simply retry on such occurrences.

The nature of appending something or prepending is that it does not matter when it is done or in which order. So prepend or append text should not throw edit-conflicts. (Yes they do and are not rare: [[:commons:MediaWiki talk:AjaxQuickDelete.js/auto-errors]])
Comment 1 Nemo 2013-03-06 09:00:40 UTC

*** This bug has been marked as a duplicate of bug 22783 ***
Comment 2 Rainer Rillke @commons.wikimedia 2013-03-06 10:30:07 UTC
I don't think this is a duplicate. While bug 22783 is always reproducible, this one is hard to. It seems to only occur when one edit is still handled while a new edit to the same page is made.
Comment 3 Umherirrender 2013-03-06 18:58:59 UTC
It is not a dupe.

I have added steps to reproduce the other bug, maybe than it is clear, which was my description about.
Comment 4 Wikid77 2013-06-14 06:29:20 UTC
This bug is easy to reproduce, by running "section=new" when another user is editing under the bottom section "==Header==". So, UserA begins editing bottom section, UserB runs "section=new" and saves to append, then UserA gets edit-conflict because the prior bottom section has new section appended.

The general fix for all these edit conflicts is to write a variation of the GNU diff3 file-merge program to allow multiple inserts (or multiple replies) at the same line number, such as the final line of a page, and to stack the multiple new entries in LIFO order ("list-in, first-out") so that insertions or replies in the prior bottom section get stacked above (LIFO order) the newly appended "section=new". At the top of a page, the 2nd editor's insertion would get stacked above any prior insertions, as the new top text in the page. By always using LIFO order (to stack multiple insertions after the same line), then any new text which contains a new section "==Topic==" would appear after the text inserted by the next editor, unaware that a new "Topic" had been created below the current line of the insertion (or reply). That ensures that the second editor's insertion is never appended into a different section, but always immediately after the line which the 2nd editor had viewed. -Wikid77
Comment 5 Liangent 2013-06-14 06:35:24 UTC
btw prepending or appending text SHOULD throw conflicts when basetimestamp is set.
Comment 6 Wikid77 2013-06-14 06:40:27 UTC
(In reply to comment #5)
> btw prepending or appending text SHOULD throw conflicts when basetimestamp is
> set.

Why not just stack the 2nd editor's insertion *above* the other prepended or appended text? -Wikid77
Comment 7 Rainer Rillke @commons.wikimedia 2013-06-14 17:03:53 UTC
I filed this bug against the API but Nemo changed it without any useful explanation. 

We had edit conflicts at Commons even when no timestamp was set. "listRequestSubpage" and "notifyUploaders" never set a timestamp.

https://commons.wikimedia.org/w/index.php?title=MediaWiki_talk%3AGadget-AjaxQuickDelete.js%2Fauto-errors%2F1&diff=68722382&oldid=68627265
Comment 8 Rainer Rillke @commons.wikimedia 2013-06-14 17:06:07 UTC
(In reply to comment #4)
> This bug is easy to reproduce, by running "section=new" when another user is
> editing under the bottom section "==Header==". So, UserA begins editing bottom
> section, UserB runs "section=new" and saves to append, then UserA gets
> edit-conflict because the prior bottom section has new section appended.

No. Not section=new. POST /w/api.php action=edit&appendtext=blablabla&token=XXX
Comment 9 Liangent 2013-06-14 17:12:34 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > btw prepending or appending text SHOULD throw conflicts when basetimestamp is
> > set.
> 
> Why not just stack the 2nd editor's insertion *above* the other prepended or
> appended text? -Wikid77

Just don't set the param then. basetimestamp makes no sense in this case ( = do prepending or appending whatever the current version looks like ).
Comment 10 Liangent 2013-06-14 17:14:27 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > btw prepending or appending text SHOULD throw conflicts when basetimestamp is
> > set.
> 
> Why not just stack the 2nd editor's insertion *above* the other prepended or
> appended text? -Wikid77

The most problematic thing is &section=. A section number extracted from an old revision isn't guaranteed to refer to the same section (by semantic) in a newer version.
Comment 11 Brad Jorsch 2013-06-14 18:24:06 UTC
Appending and prepending text absolutely *should* throw edit conflicts. If two people try to prepend text at the same time, you cannot assume that "A B orig" (or "B A orig") is what either of them might have intended any more than you can assume that edits "orig1 A orig2" and "orig1 B orig2" should result in "orig1 A B orig2".

Consider for a particularly silly example where one person from the US prepends "{{cleanup|reason=The article is demonizing the subject}}" and one from the UK prepends "{{cleanup|reason=The article is demonising the subject}}". You'd end up with two tags at the top of the article saying effectively the same thing.

Real-life cases aren't usually this clearly ridiculous, but they occur often enough that were this bug fixed we'd certainly start to get bugs that edit conflicts were not being raised when people try to append or prepend the same thing at the same time. And that would be more hassle to clean up, because someone has to notice and then make a third edit to merge things. New sections on talk pages are the one exception to this, which is already filed as bug 22783.

Thus, I'm going to close this as WONTFIX.


Also, for background:

An edit conflict happens any time that the submitted basetimestamp (wpEdittime in the GUI) is not the same as the timestamp on the most recent revision of the article. Every single time. But sometimes the conflict can be automatically resolved, if the changes from base→current and base→submitted can be merged. Improving this automatic edit conflict resolution is outside the scope of a bug against the API, and it would not surprise me if a bug about that already exists.

The API's appendtext and prependtext take the existing page content, append/prepend the text, and then treat it as if it were an edit of the entire page. This is the only way it can work until someone rewrites EditPage, which is also outside the scope of a bug against the API. This is also how section editing (particularly section=new) works, which is probably why Nemo marked this as a duplicate of the new-section bug.


(In reply to comment #7)
> We had edit conflicts at Commons even when no timestamp was set.
> "listRequestSubpage" and "notifyUploaders" never set a timestamp.

There are various possibilities for that. For example, if someone else's edit gets saved in between when ApiEditPage chooses a default basetimestamp for you and when EditPage actually checks for an edit conflict, that could do it. This could be more likely if ApiEditPage fetched that default basetimestamp from a lagged slave.


(In reply to comment #4)
> The general fix for all these edit conflicts is to write a variation of the
> GNU diff3 file-merge program

Feel free to do so. Or hire someone to do it for you, if you lack the necessary skills. Or convince someone else that they should pay someone to do it for you.

What's not going to get it done is just asserting that "someone" should do it in every tangentially-related discussion.
Comment 12 Umherirrender 2013-06-14 18:27:13 UTC
(In reply to comment #4)
> This bug is easy to reproduce, by running "section=new" when another user is
> editing under the bottom section "==Header==". So, UserA begins editing
> bottom
section, UserB runs "section=new" and saves to append, then UserA
> gets
edit-conflict because the prior bottom section has new section
> appended.

That is bug 22783

(In reply to comment #9)

> Just don't set the param then. basetimestamp
> makes no sense in this case ( = do
> prepending or appending whatever the
> current version looks like ).

That is, was Rillke has wrote in comment 7

No basetimestamp, but edit conflicts.
Comment 13 Liangent 2013-06-14 18:49:36 UTC
(In reply to comment #11)
> Appending and prepending text absolutely *should* throw edit conflicts. If
> two
> people try to prepend text at the same time, you cannot assume that "A B
> orig"
> (or "B A orig") is what either of them might have intended any more than you
> can assume that edits "orig1 A orig2" and "orig1 B orig2" should result in
> "orig1 A B orig2".
> 
> Consider for a particularly silly example where one person from the US
> prepends
> "{{cleanup|reason=The article is demonizing the subject}}" and one from the
> UK
> prepends "{{cleanup|reason=The article is demonising the subject}}". You'd
> end
> up with two tags at the top of the article saying effectively the same thing.
> 
> Real-life cases aren't usually this clearly ridiculous, but they occur often
> enough that were this bug fixed we'd certainly start to get bugs that edit
> conflicts were not being raised when people try to append or prepend the same
> thing at the same time. And that would be more hassle to clean up, because
> someone has to notice and then make a third edit to merge things. New
> sections
> on talk pages are the one exception to this, which is already filed as bug
> 22783.
> 
> Thus, I'm going to close this as WONTFIX.
> 

If someone is expecting the fact that there is no {{cleanup}} before their edit, I believe they have downloaded wikitext (or rendered HTML) of the original version, and checked there's no existing {{cleanup}}, before submitting their edit. Now a basetimestamp which triggers edit conflict makes sense here.

> 
> Also, for background:
> 
> An edit conflict happens any time that the submitted basetimestamp
> (wpEdittime
> in the GUI) is not the same as the timestamp on the most recent revision of
> the
> article. Every single time. But sometimes the conflict can be automatically
> resolved, if the changes from base→current and base→submitted can be merged.
> Improving this automatic edit conflict resolution is outside the scope of a
> bug
> against the API, and it would not surprise me if a bug about that already
> exists.
> 
> The API's appendtext and prependtext take the existing page content,
> append/prepend the text, and then treat it as if it were an edit of the
> entire
> page. This is the only way it can work until someone rewrites EditPage, which
> is also outside the scope of a bug against the API. This is also how section
> editing (particularly section=new) works, which is probably why Nemo marked
> this as a duplicate of the new-section bug.
> 

If no base revision is specified, the API module can just take the new version, re-apply appendtext or prependtext on it, then try saving again.

> 
> (In reply to comment #7)
> > We had edit conflicts at Commons even when no timestamp was set.
> > "listRequestSubpage" and "notifyUploaders" never set a timestamp.
> 
> There are various possibilities for that. For example, if someone else's edit
> gets saved in between when ApiEditPage chooses a default basetimestamp for
> you
> and when EditPage actually checks for an edit conflict, that could do it.
> This
> could be more likely if ApiEditPage fetched that default basetimestamp from a
> lagged slave.
> 
> 
> (In reply to comment #4)
> > The general fix for all these edit conflicts is to write a variation of the
> > GNU diff3 file-merge program
> 
> Feel free to do so. Or hire someone to do it for you, if you lack the
> necessary
> skills. Or convince someone else that they should pay someone to do it for
> you.
> 
> What's not going to get it done is just asserting that "someone" should do it
> in every tangentially-related discussion.
Comment 14 Rainer Rillke @commons.wikimedia 2013-06-14 19:14:56 UTC
(In reply to comment #11)
> Appending and prepending text absolutely *should* throw edit conflicts
But only if you set one of the timestamps. That's why there are such timestamps. If you don't set them, you make clear that you don't care. In case of notifyUploaders and listRequestSubpage, it really doesn't matter.

I agree with Liangent that the API should try to re-apply appendtext or prependtext. But this is nothing critical as client side logic can handle this. It is just unexpected behaviour.
Comment 15 Brad Jorsch 2013-06-14 21:04:44 UTC
(In reply to comment #13)
>
> If no base revision is specified, the API module can just take the new
> version, re-apply appendtext or prependtext on it, then try saving again.

Personally, I think basetimestamp should be a required parameter.

If you really want to submit a changeset to make it work this way, go ahead.
Comment 16 Rainer Rillke @commons.wikimedia 2013-06-14 22:00:07 UTC
(In reply to comment #15)
> Personally, I think basetimestamp should be a required parameter.
Don't even attempt. Commons Buzzard would be very upset... at least as long as we must use wikipages to compile lists that can't be hijacked as easy as categories.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links