Page MenuHomePhabricator

edit with basetimestamp fails if the page has been deleted and undeleted since the last edit
Closed, ResolvedPublic

Description

This is regarding r40356, as installed on en.wikipedia.org.

If the page has been deleted and then undeleted since the last edit, an attempted edit using the API will fail with an error message "The page has been deleted since you fetched its timestamp". This can happen if an admin is trying to remove vandalism from the public page history: he deletes the page, and then undeletes all but the troublesome revision.

For example, [[en:Talk:Cambrian explosion]] currently shows that it was most recently edited on September 13,[1] while the logs for that page show it was deleted and undeleted on September 16.[2] The timestamp picked up from the rvprop query is of course 20080913031053 from the edit.

If the "touched" date from prop=info would work to prevent edit conflicts, a fix could be to just change the documentation of basetimestamp to suggest using that instead of rvprop's timestamp (unless "touched" isn't really updated by undeletion?). Otherwise, intoken would probably have to return the appropriate basetimestamp explicitly in addition to the edit token.

[1] http://en.wikipedia.org/w/index.php?title=Talk:Cambrian_explosion&action=history
[2] http://en.wikipedia.org/w/index.php?title=Special:Log&page=Talk%3ACambrian_explosion


Version: unspecified
Severity: enhancement

Details

Reference
bz15647

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:17 PM
bzimport set Reference to bz15647.

Weird... the API just wraps around EditPage, so there should be no difference between the UI and the API in this matter. I'll investigate.

I see in r41137 ApiEditPage.php you set both wpEdittime and wpStarttime to the basetimestamp value, while loading the edit form on en.wikipedia.org sets wpStarttime to the timestamp of when the edit form is first loaded instead. Does the API need to have a starttime value passed in addition to basetimestamp? If so, could it also return the current timestamp in the responses (at least those with an edit token) so we don't have to worry about clock sync issues?

Created attachment 5368
This patch (against r41332) works for me in a local MediaWiki installation

This patch (against r41332) works for me in a local MediaWiki installation. It adds a "starttimestamp" option to the edit action, defaulting to the current behavior if the parameter is not provided. It also adds a "starttimestamp" value to the prop=info output when a token is returned to avoid any clock skew issues.

Attached:

Patch applied in r41649, credit given in r41650