• This bug has been marked as a duplicate of bug 22783 ***

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.

It is not a dupe.

I have added steps to reproduce the other bug, maybe than it is clear, which was my description about.

bswanberg77 wrote:

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

btw prepending or appending text SHOULD throw conflicts when basetimestamp is set.

bswanberg77 wrote:

(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

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

(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

(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 ).

(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.

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.

(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.

(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

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.

(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.

(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.

(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.