Page MenuHomePhabricator

Use of starttimestamp or basetimestamp in API calls doesn't seem to prevent edit conflicts
Open, Needs TriagePublicBUG REPORT

Description

List of steps to reproduce (step by step, including full links if applicable):

  • Have a page with content
  • Add some crap to said page
  • Log in as a different user, take the previous page version, edit it in a different conflicting way, make API call with a timestamp that predates the timestamp for the previous edit.
var api = new mw.Api();
api.postWithEditToken( {
format: 'json', title: 'User_talk:AJ-test', action: 'edit', summary: 'test', text: '==section test 1==\ntest barfoo4 this edit has a starttimestamp of 2022-01-20T22:36:00Z', starttimestamp: '2022-01-20T22:36:00Z'
} ).done( function ( data ) {
} );

What happens?:
https://commons.wikimedia.beta.wmflabs.org/w/index.php?title=User_talk:AJ-test&diff=258465&oldid=258464 the text "This addition should not be removed" which was added at 22:37 was removed by an edit with a starttimestamp of 2022-01-20T22:36:00Z. (see code)

What should have happened instead?:
The edit should have been rejected as there was an edit conflict.

Noting that I also just tried to break https://commons.wikimedia.beta.wmflabs.org/w/index.php?title=User_talk:AJ-test&diff=258466&oldid=258465 with an edit with baserevid 258465, but that did result in an edit conflict. So adding baserevid prevents edit conflicts but starttimestamp doesn't.

Event Timeline

var api = new mw.Api();
api.postWithEditToken( {
format: 'json', title: 'User_talk:AJ-test', action: 'edit', summary: 'test', text: '==section test 1==\ntest barfoo7 this edit has a basetimestamp of 2022-01-20T22:56:34Z', basetimestamp: '2022-01-20T22:56:34Z'
} ).done( function ( data ) {
} );

Result: https://commons.wikimedia.beta.wmflabs.org/w/index.php?title=User_talk:AJ-test&diff=258468&oldid=258467

2022-01-20T22:56:34Z is what https://commons.wikimedia.beta.wmflabs.org/w/api.php?action=query&prop=revisions&rvprop=timestamp&titles=User%20talk:AJ-test had returned me for an older revision. So basetimestamp doesn't seem to work either. (should I ask why basetimestamp even exists? what's the advantage over using starttimestamp if the revision is unknown or baserevid if the revision is known?)

AlexisJazz renamed this task from Use of starttimestamp doesn't seem to prevent edit conflicts to Use of starttimestamp or basetimestamp in API calls doesn't seem to prevent edit conflicts.Jan 20 2022, 11:14 PM

I think the intended usage is to specify both starttimestamp and basetimestamp:

  • starttimestamp is the timestamp of when the user opened the editor, you can ask MediaWiki for the current time by adding &curtimestamp=1 to any other query, example (this avoids dealing with timezones, time formatting, and unsynchronized clocks between the client and server)
  • basetimestamp is the timestamp of the latest revision of the page at the time when the user opened the editor, obtained from the prop=revisions query (you can get the page wikitext using the same query)

Note that basetimestamp is almost-but-not-quite deprecated (T58849), and baserevid should be used instead.

I think the intended usage is to specify both starttimestamp and basetimestamp:

  • starttimestamp is the timestamp of when the user opened the editor, you can ask MediaWiki for the current time by adding &curtimestamp=1 to any other query, example (this avoids dealing with timezones, time formatting, and unsynchronized clocks between the client and server)
  • basetimestamp is the timestamp of the latest revision of the page at the time when the user opened the editor, obtained from the prop=revisions query (you can get the page wikitext using the same query)

Note that basetimestamp is almost-but-not-quite deprecated (T58849), and baserevid should be used instead.

api.postWithEditToken( {
format: 'json', title: 'User_talk:AJ-test', action: 'edit', summary: 'test', text: '==section test 1==\ntest barfoo8 this edit has a basetimestamp and starttimestamp of 2022-01-20T22:56:34Z', starttimestamp: '2022-01-20T22:56:34Z', basetimestamp: '2022-01-20T22:56:34Z'
} )

Yeah, that got rejected as an edit conflict!
Okay. If you don't mind me asking: why do starttimestamp and basetimestamp exist and why would both be required? If you have basetimestamp, you could just throw starttimestamp away. If you have starttimestamp, you could simply look for the last revision that predates starttimestamp. The only point of that is to avoid making a client-side request to obtain the actual revision ID/time. But if starttimestamp doesn't work without basetimestamp, what's the point anyway?

Could https://en.wikipedia.org/w/api.php?action=help&modules=edit be updated to reflect what you said? I don't mind this feature being dead or deprecated (in my case I can just use baserevid instead, I was already obtaining some page export anyway), but the help page suggested starttimestamp was a valid solution. No indication that it wouldn't work without basetimestamp or that baserevid is preferred.

starttimestamp is to detect conflicts with page deletion and avoids recreation of the page if deleted in the meantime
basetimestamp/baserevid is used for edit conflict detection and avoids override of the page content if edited in the meantime

starttimestamp is to detect conflicts with page deletion and avoids recreation of the page if deleted in the meantime
basetimestamp/baserevid is used for edit conflict detection and avoids override of the page content if edited in the meantime

Now I get it.

Okay, suggested text for https://en.wikipedia.org/w/api.php?action=help&modules=edit if I understood all correctly:

baserevid: ID of the base revision, used to detect edit conflicts including self-conflicts. May be obtained through action=query&prop=revisions. Self-conflicts cause the edit to fail unless basetimestamp is set.

basetimestamp: Timestamp of the base revision, used to detect edit conflicts excluding self-conflicts. May be obtained through action=query&prop=revisions&rvprop=timestamp. When possible and appropriate it is recommended to use baserevid instead.

starttimestamp: Timestamp when the editing process began, used to prevent recreation of the page if it was deleted after the editing process began. An appropriate value may be obtained using curtimestamp when beginning the edit process (e.g. when loading the page content to edit).

@matmarex I just tested and basetimestamp and starttimestamp can work independently from each other, but starttimestamp only cares about recreation. In a previous test of basetimestamp I accidentally made a self-conflict which basetimestamp is supposed to ignore.