Well, error handling seems covered in bug 28132

Seems that an edit conflict is detected for all users, but the check to see if you're conflicting against yourself (which suppresses the conflict) doesn't apply to anonymous users.

I don't understand how these are conflicts though:

timestamp: 20130425193332, edittime: 20130813191144
EditPage::internalAttemptSave: conflict! getting section '' for time '20130813191144' (article time '20130425193332')

This is determined by a check in EditPage::internalAttemptSave:
$timestamp != $this->edittime

I wonder if that != should be a >=...

I've looked to what params are posted when the edit is saved, and they are:

• action=threadaction
• threadaction=edit
• thread=<THREAD ID>
• text=<MESSAGE TEXT>
• render=1
• reason=<EDIT SUMMARY>
• bump=true
• signature=<SIGNATURE>
• token=<TOKEN>

Compared to a normal edit page, or what params are available to http://www.mediawiki.org/wiki/API:Edit for edit conflict resolution, LQT seems incomplete.

It should get a "basetimestamp" along with the edit form, with the timestamp of the last edit of that message, and send it when the edit is saved, and pass it to the edit conflict resolution logic. Otherwise there's no way to detect conflicts because it doesn't know from what revision/timestamp the edit was started.

If you read the code for LQT's threadaction you'll see that it deals with basetimestamp. We know this is happening because otherwise no conflicts would be detected.

(In reply to comment #5)

If you read the code for LQT's threadaction you'll see that it deals with
basetimestamp. We know this is happening because otherwise no conflicts would
be detected.

So this is not related in any way to bug 34580?

(In reply to comment #5)

If you read the code for LQT's threadaction you'll see that it deals with
basetimestamp. We know this is happening because otherwise no conflicts would
be detected.

As I said, when you save the edit, the server isn't getting that basetimestamp.

Yes, I see how it's "dealing" with it:

'basetimestamp' => wfTimestampNow(),

That's wrong, since there's no way to know from which "revision" the edit was started. Maybe someone else saved the edit before you, but LQT has no reference to detect it.

The workflow should be:

1. A request is made to get an edit form of a message
2. LQT should send the basetimestamp of the current message along with the edit form
3. The user hits save.
4. A request is made with all the current fields plus the basetimestamp received in #2
5. LQT should use it to detect edit conflicts, instead of generating a reference basetimestamp from wfTimestampNow()

Editing a message should be like editing any normal page (if I haven't understood it wrong). Every message is like a page.

I wonder if the bug summary is still correct: https://www.mediawiki.org/w/index.php?title=Thread:Help_talk:CirrusSearch/Does_incategory_locate_articles_with_transcluded_categories%3F&lqt_method=thread_history

Diffs don't help much. RC doesn't show anything, as usual, so it's hard to tell. https://www.mediawiki.org/w/index.php?title=Special:RecentChanges&limit=500&hideliu=1&namespace=90&days=30