Page MenuHomePhabricator

API should return error if External Store master not available - Pages not created on Commons
Open, MediumPublic

Description

Several reports at the Commons about non-existing pages that should exist. Examples at the time of writing:

https://commons.wikimedia.org/wiki/Commons:Deletion_requests/Files_in_Category:De_Gesammelte_Abhandlungen_%28Hertz_W%29

Page should have been created at 2012-06-12, 00:01 UTC according to https://commons.wikimedia.org/w/index.php?title=Commons:Deletion_requests/2012/06/12&action=history

Probably the user used https://commons.wikimedia.org/wiki/MediaWiki:Gadget-AjaxQuickDelete.js to create this deletion nomination.

Then there's a whole series of uploaded files: https://commons.wikimedia.org/w/index.php?title=Commons:Administrators%27_noticeboard&oldid=72480417#Flickr2Commons_upload_bug

Presumably, Magnus's tool also uses the API to create pages. These files were uploaded around 2012-06-11 23:51 UTC.

In all cases, the page reports "The database did not find the text of a page that it should have found..."

Can this be related to the DB master switch around that time?

https://wikitech.wikimedia.org/view/Server_admin_log#June_12


Version: unspecified
Severity: major
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=32551

Details

Reference
bz37480

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:26 AM
bzimport set Reference to bz37480.
bzimport added a subscriber: Unknown Object (MLST).

afeldman wrote:

This was a result of the External Store master crashing. Between roughly 2012-06-11 23:48 (es1 crashing) and 23:52 (promoting es1 to master), it was not possible to save revision text, requisite for page creation.

Presumably we should really block the upload if we can't write the page?

(In reply to comment #3)

Presumably we should really block the upload if we can't write the page?

One would hope it would be wrapped in a transaction, and rollback on failure and go LOLNO

Bryan.TongMinh wrote:

(In reply to comment #4)

(In reply to comment #3)

Presumably we should really block the upload if we can't write the page?

One would hope it would be wrapped in a transaction, and rollback on failure
and go LOLNO

I remember fixing a similar bug before, but that was when writing to the page table failed. Apparently failure to store the text has a different failure path.

Bryan.TongMinh wrote:

Moving back to General/Unknown, as I misread the original bug report; also non-file pages are affected.

As for the uploading, this is really bug 15430 in another incarnation.

(In reply to comment #2)

This was a result of the External Store master crashing. Between roughly
2012-06-11 23:48 (es1 crashing) and 23:52 (promoting es1 to master), it was
not possible to save revision text, requisite for page creation.

The goal of this bug report is not clear to me. Make sure this does not happen again next time it crashes, by blocking uploads somehow?

(In reply to comment #7)

The goal of this bug report is not clear to me. Make sure this does not happen
again next time it crashes, by blocking uploads somehow?

At least the API should return an error. As for the deletion requests, the API must have responded something different than "error". Otherwise the non-existant page wouldn't have been listed to the 2012/06/12 page.

And I agree that uploads (at least moving from stash to target) should be blocked when the text revision can't be created.