Last modified: 2014-02-28 22:21:27 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 15430 - Uploads sometimes are incomplete: file is there, but image page is missing
Uploads sometimes are incomplete: file is there, but image page is missing
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Uploading (Other open bugs)
unspecified
All All
: High normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
: 34228 37394 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-01 20:31 UTC by Lupo
Modified: 2014-02-28 22:21 UTC (History)
23 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch (659 bytes, patch)
2008-11-06 23:00 UTC, Bryan Tong Minh
Details
Updated patch (3.08 KB, patch)
2009-01-03 15:36 UTC, Bryan Tong Minh
Details
Delete image row on Article::doEdit failure (2.45 KB, patch)
2011-02-12 17:59 UTC, Bryan Tong Minh
Details
Screenshot showing the issue. Uploader of the photo this is a derivative of is https://commons.wikimedia.org/wiki/User:Red_Castle - License: unknown (280.91 KB, image/png)
2013-12-13 14:39 UTC, Rainer Rillke @commons.wikimedia
Details

Description Lupo 2008-09-01 20:31:38 UTC
We've had at the Commons recently several cases where uploads were not done completely. The images showed up, the file history showed even the full upload summary, but the corresponding image description pages were not created. As a result, if the user used the license dropdown to specify the license, that license was lost completely (because it doesn't show up in the upload summary).

An example is http://commons.wikimedia.org/wiki/Image:Palencia_-_San_Pablo_15.JPG the image page was created manually on the day after the upload, see the page history at http://commons.wikimedia.org/w/index.php?title=Image:Palencia_-_San_Pablo_15.JPG&action=history . The uploader was notified and did add the license after that, so all is well for this image now. But there are other such images where the licenses were lost, and where the uploaders did not react.

I've observed this behavior twice so far, once on July 31 from about 10:30 to 11:50 UTC, and now on August 31 from 17:19 to 17:39 UTC.

See also http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/Archive_10#Server_hiccups and http://commons.wikimedia.org/w/index.php?title=Commons:Administrators%27_noticeboard/Attention&oldid=14027516#Problems_with_upload
Comment 1 Roan Kattouw 2008-09-01 20:33:33 UTC
Assigning to Bryan as he rewrote the image handling code recently.
Comment 2 Bryan Tong Minh 2008-09-01 20:40:40 UTC
The new code is not active yet on Wikimedia.
Comment 3 Roan Kattouw 2008-09-01 20:42:26 UTC
(In reply to comment #2)
> The new code is not active yet on Wikimedia.
> 

Hmm. In that case, assigned to you because you know a lot about that part of the code ;)

Seriously, though, it would probably be worth investigating/trying whether your rewrite fixes this.
Comment 4 Lupo 2008-09-01 20:43:08 UTC
Here's another example where it's even more evident that there was no image
page:
http://commons.wikimedia.org/wiki/Image:Basketball_29082008666_(5).jpg

The only edit to the image page was my nominating it for deletion:
http://commons.wikimedia.org/w/index.php?title=Image:Basketball_29082008666_(5).jpg&action=history
Comment 5 Platonides 2008-09-01 20:50:23 UTC
http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/Archive_10#Server_hiccups mentions "a bunch of wiki has a problem messages around that time"
I think this may be the same problem reported on #wikimedia-tech, with some apache trying to write to the old master (now read only) on external storage.
I recommend adding some check to the upload code for the case where the description can't be saved.

IRC reports were as follows (UTC time):
16:15:56 <[X]> The last attempted database query was: (SQL query hidden) from within function "ExternalStoreDB::store". MySQL returned error "1290: The MySQL server is running with the --read-only option so it cannot execute this statement (10.0.2.102)".
17:18:30 <Mike_lifeguard> ...within function "ExternalStoreDB::store". MySQL returned error "1290: The MySQL server is running with the --read-only option so it cannot execute this statement (10.0.2.107)".
Comment 6 Bryan Tong Minh 2008-09-01 20:55:25 UTC
Apparently LocalFile::recordUpload2 continues unconditionally after Article::doEdit without any error checking whatsoever. Should be fixed.
Comment 7 Roan Kattouw 2008-09-02 12:22:16 UTC
(In reply to comment #5)
> http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/Archive_10#Server_hiccups
> mentions "a bunch of wiki has a problem messages around that time"
> I think this may be the same problem reported on #wikimedia-tech, with some
> apache trying to write to the old master (now read only) on external storage.
> I recommend adding some check to the upload code for the case where the
> description can't be saved.
> 
> IRC reports were as follows (UTC time):
> 16:15:56 <[X]> The last attempted database query was: (SQL query hidden) from
> within function "ExternalStoreDB::store". MySQL returned error "1290: The MySQL
> server is running with the --read-only option so it cannot execute this
> statement (10.0.2.102)".
> 17:18:30 <Mike_lifeguard> ...within function "ExternalStoreDB::store". MySQL
> returned error "1290: The MySQL server is running with the --read-only option
> so it cannot execute this statement (10.0.2.107)".
> 

Related to bug 15391?
Comment 8 Mike.lifeguard 2008-09-02 15:26:14 UTC
(In reply to comment #5)
> IRC reports were as follows (UTC time):
> 17:18:30 <Mike_lifeguard> ...within function "ExternalStoreDB::store". MySQL
> returned error "1290: The MySQL server is running with the --read-only option
> so it cannot execute this statement (10.0.2.107)".
> 

That one was attempting to save either [[m:Talk:Spam blacklist]] or [[m:Spam blacklist]] (forget which one) not uploading an image. Not sure whether that's relevant or not though.
Comment 9 Aaron Schulz 2008-09-05 03:48:44 UTC
(In reply to comment #6)
> Apparently LocalFile::recordUpload2 continues unconditionally after
> Article::doEdit without any error checking whatsoever. Should be fixed.
> 

Yeah, looks like bad transaction wrapping there.
Comment 10 Aaron Schulz 2008-09-05 04:12:42 UTC
Still, LB should rollback the last transaction if a db failure comes up.
Comment 11 Lupo 2008-11-06 14:26:26 UTC
Two more of these, uploaded 2008-09-12:

http://commons.wikimedia.org/wiki/Image:Fibersensing.JPG

http://commons.wikimedia.org/wiki/Image:Audolici.JPG

Any progress on this issue? Since we do lose licensing information when this occurs, this is a pretty serious failure, even if I haven't seen it anymore recently. Has this been fixed or not?
Comment 12 Bryan Tong Minh 2008-11-06 23:00:43 UTC
Created attachment 5506 [details]
Patch

This patch checks the result of Article::doEdit.

I am not sure whether I did the transaction stuff correctly. Somebody review.
Comment 13 Bryan Tong Minh 2008-12-26 19:42:49 UTC
Fixed in r45058.
Comment 14 Brion Vibber 2008-12-31 17:25:28 UTC
Reverted in r45230

Article::doEdit() opens and commits transactions of its own, so the transaction we started earlier will already be committed and cannot be rolled back at this point unless one of two particular failure modes hits (ArticleSave hook aborts or mLatest isn't set). A more general fix needs to be devised...
Comment 15 Bryan Tong Minh 2009-01-03 15:36:09 UTC
Created attachment 5643 [details]
Updated patch

Patch that swaps the order around: first the article is editted and if that succeeded the upload is recorded.

Can't test it myself atm because my PHP uploading is broken.
Comment 16 Brion Vibber 2009-01-04 03:47:59 UTC
This seems like it would be more likely to break, and in a less recoverable fashion.

Current order of operations appears to be:

1) Physically move in the file
2) Save 'image'/'oldimage' record
3) Save log entry
4) Add/update description page

Failing at the page save at least should leave us with a working file record, history, and log update, unless we hit a rare case where the actual image record update gets rolled back [if the log and page saves don't start any transactions, but then fail].

Order of operations for the patch is:

1) Physically move in the file
2) Add/update description page
3) Save 'image'/'oldimage' record
4) Save log entry

If we fail at 2) now, we have a file sitting around with no record. If this is an update to an existing file, we have a broken history and an untraceable, unexplained, unlogged change -- very bad.

Either we need to accept that failing the page is ok, or we need to be able to roll back the change to the actual file -- or else do it after, and be able to roll back all our DB and page updates if the file move fails. Icky. :(
Comment 17 Bryan Tong Minh 2009-01-04 22:01:09 UTC
(In reply to comment #16)

> Order of operations for the patch is:
> 
> 1) Physically move in the file
> 2) Add/update description page
> 3) Save 'image'/'oldimage' record
> 4) Save log entry
> 
> If we fail at 2) now, we have a file sitting around with no record. If this is
> an update to an existing file, we have a broken history and an untraceable,
> unexplained, unlogged change -- very bad.
> 
In case this is an existing file, we never reach Article::doEdit, so it can never fail at that.

> Either we need to accept that failing the page is ok, or we need to be able to
> roll back the change to the actual file -- or else do it after, and be able to
> roll back all our DB and page updates if the file move fails. Icky. :(
> 
What I think is that we should accept that LocalFile::recordUpload2 does not always succeed. In case it doesn't it should be guaranteed that it did not make any changes and leave it to the caller to clean up the file.

The current situation is that in case it fails, it may or may not leave a log entry depending on what caused the failure. This seems to me less desirable than a clear guarantee that no log entry has been left.
Comment 18 Brion Vibber 2009-01-05 18:59:40 UTC
(In reply to comment #17)
> In case this is an existing file, we never reach Article::doEdit, so it can
> never fail at that.

Mmm, true. That should simplify things a bit at least. :)

> > Either we need to accept that failing the page is ok, or we need to be able to
> > roll back the change to the actual file -- or else do it after, and be able to
> > roll back all our DB and page updates if the file move fails. Icky. :(
> > 
> What I think is that we should accept that LocalFile::recordUpload2 does not
> always succeed. In case it doesn't it should be guaranteed that it did not make
> any changes and leave it to the caller to clean up the file.
> 
> The current situation is that in case it fails, it may or may not leave a log
> entry depending on what caused the failure. This seems to me less desirable
> than a clear guarantee that no log entry has been left.

We might want to consider what happens if various parts fail. Eg, if the edit succeeds, but the log entry fails, then we have to delete the page, the image record, and the file?
Comment 19 Lupo 2009-02-09 21:58:30 UTC
Another one:

http://commons.wikimedia.org/wiki/File:Croke_Park_fans_on_the_hill.jpg

uploaded 2009-02-08, 19:13 (UTC)
Comment 20 Lupo 2009-06-10 17:17:48 UTC
And again:

http://commons.wikimedia.org/wiki/File:Rubik%27s_Cube_Beginner%27s_Method_-_after_step_0.svg

uploaded 2009-06-10, 11:54 (UTC), corrected manually. License was known in this case because the uploader told us at

http://commons.wikimedia.org/w/index.php?title=Commons:Forum&oldid=22211254#Fehler_beim_Hochladen

(in German).
Comment 21 Lupo 2009-07-09 11:28:00 UTC
See

http://commons.wikimedia.org/wiki/User:Ilmari_Karonen/Zombie_images

for a list of more such images without description page (and, unfortunately, without licensing info).
Comment 22 Platonides 2009-12-02 15:21:16 UTC
http://commons.wikimedia.org/wiki/File:Arepas_cooked_with_firewood.jpg file and image entry is there but no image page or log entry.
It was uploaded at today's swapdeath of the servers.
Comment 23 Lupo 2010-05-17 09:54:21 UTC
And another one:

http://commons.wikimedia.org/wiki/File:1000_Minin.jpg

Uploaded 2010-05-17, image page was created only when the file was tagged as "no permission".
Comment 24 Bryan Tong Minh 2011-02-12 17:59:44 UTC
Created attachment 8136 [details]
Delete image row on Article::doEdit failure

Cooked up something simpler: since we know that the only thing that we did before editing the article is adding a row to the image table, we can safely delete this row.
Comment 25 Bryan Tong Minh 2011-02-12 18:01:47 UTC
(In reply to comment #24)
> Created attachment 8136 [details]
> Delete image row on Article::doEdit failure
> 
*sigh*

The condition before deleting should obviously be ( !$reupload && !status->isOk() )
Comment 26 Platonides 2011-02-12 22:46:47 UTC
Looks acceptable, given that we're not going to get consensus on doing the transaction bigger, which is what really should be done, due to fear of locks. I would perform an explicit commit before doEdit(), though.
Comment 27 p858snake 2011-04-30 00:10:06 UTC
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Comment 28 mabdul 2012-06-21 13:30:33 UTC
I'm not sure if that belongs into this bug report: https://en.wikipedia.org/wiki/File:Aljazeera.svg was deleted and restored, but while restoring something went wrong - the image was available but not the description page. An user in #wikimedia-commons was aware of this bug and told the workaround is to delete and restore the image again, see log at https://en.wikipedia.org/w/index.php?title=Special:Log&page=File%3AAljazeera.svg
Comment 29 Nemo 2012-08-23 08:49:24 UTC
*** Bug 34228 has been marked as a duplicate of this bug. ***
Comment 30 Derk-Jan Hartman 2012-08-25 22:01:37 UTC
*** Bug 37394 has been marked as a duplicate of this bug. ***
Comment 31 Bryan Tong Minh 2012-09-23 21:14:30 UTC
(In reply to comment #24)
> Created attachment 8136 [details]
> Delete image row on Article::doEdit failure
> 
> Cooked up something simpler: since we know that the only thing that we did
> before editing the article is adding a row to the image table, we can safely
> delete this row.

Getting back to this again, my original reasoning was wrong. There are four possible cases:

1. File does not exist, page does not exist
2. File does not exist, page does exist
3. File does exist, page does not exist
4. File does exist, page does exist

In cases 3 & 4 we move the image row to oldimage, which is a cumbersome operation to recover. In case 1 & 3 we call Article::doEdit(), which potentially fails. If Article::doEdit() fails, and we are in case 3, this patch leaves a dangling oldimage row with no image row.
Comment 32 Rainer Rillke @commons.wikimedia 2013-12-13 14:39:39 UTC
Created attachment 14083 [details]
Screenshot showing the issue. Uploader of the photo this is a derivative of is https://commons.wikimedia.org/wiki/User:Red_Castle - License: unknown

This happened again at https://commons.wikimedia.org/wiki/File:D%C3%A9l%C3%A9gation_g%C3%A9n%C3%A9rale_du_Qu%C3%A9bec_%C3%A0_Londres_2013.JPG and 
https://commons.wikimedia.org/wiki/File:Montreal_Place_Londres_2013.JPG

Timeframe: 2013-12-13 01:54:00  -  2013-12-13 01:54:00

Their uploads are also not listed under their contributions: https://commons.wikimedia.org/wiki/Special:Contributions/Red_Castle

    (change visibility) 01:46, 13 December 2013 (diff | hist) . . (+1,221)‎ . . N User:Red Castle ‎ (←Created page with 'Bonjour, je s...') (current)
    (change visibility) 01:45, 13 December 2013 (diff | hist) . . (0)‎ . . User:Dr Wilson ‎ (→‎Licence) (current) [rollback: 1 edit]
    (change visibility) 06:35, 8 November 2013 (diff | hist) . . (+389)‎ . . User talk:Harfang ‎ (→‎Drapeau de l'Acadie: new section) (current) [rollback: 1 edit]


Another user was also affected:
https://commons.wikimedia.org/wiki/File:Ghost_creepy_2013-12-12_17-52.jpg
Comment 34 Rainer Rillke @commons.wikimedia 2013-12-16 20:00:34 UTC
https://commons.wikimedia.org/wiki/Commons:Village_pump#Upload_wizard_error

I got a weird error when I uploaded [[File:Facebook users by age population pyramid.png]]. When I try to tag it for deletion, I get "edit conflict". Can someone delete it? The correct file is at [[File:P opulation pyramid of Facebook users by age.png]]. --Dennis Bratland (talk) 03:29, 16 December 2013 (UTC)

----
The revision #0 of the page named "Facebook users by age population pyramid.png" does not exist.
Comment 36 Fabrice Florin 2013-12-18 19:43:33 UTC
Thank you all for bringing up this issue, which has gone on too long.

This issue will require major re-architecture work. We plan to revisit it in coming weeks as part of next quarter's improvements to the upload pipeline by the multimedia team. We will post here again once we have discussed possible solutions as a team in early January.

Thanks for your patience, and sorry we haven't been able to address this sooner.
Comment 38 Andre Klapper 2014-02-26 16:54:40 UTC
(In reply to Fabrice Florin from comment #36)
> Thank you all for bringing up this issue, which has gone on too long.
> 
> This issue will require major re-architecture work. We plan to revisit it in
> coming weeks as part of next quarter's improvements to the upload pipeline
> by the multimedia team. We will post here again once we have discussed
> possible solutions as a team in early January.

Fabrice: Any news?
Comment 39 Tisza Gergő 2014-02-28 21:02:55 UTC
Unassigning, I have been working exclusively on MediaViewer for the last two months, and that probably won't change for a while.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links