Last modified: 2014-11-20 13:36:20 UTC
Since a few days I get reports, incl. from myself as Wikimedia Commons uploader, like "Internal error: Could not determine if the copy succeeded." after click to submit the descriptions. Clicking on "Retry failed uploads" I get "[api-error-internal_api_error_UploadStashFileNotFoundException]" For my uploads the file uploads were completed anyway but I hear about half done uploads (file page without file).
Also mentioned here: https://commons.wikimedia.org/w/index.php?title=Commons:Upload_Wizard_feedback&oldid=87975667#Internal_error:_Could_not_determine_if_the_copy_succeeded. https://commons.wikimedia.org/w/index.php?title=Commons:Upload_Wizard_feedback&oldid=87975667#Internal_error:_Could_not_determine_if_the_copy_succeeded._2
Reproduced on James_F's laptop, but the files actually completed.
Not sure if this is a dupe of https://bugzilla.wikimedia.org/show_bug.cgi?id=36587
Is this fixed now? Or are there any steps to reproduce this?
*** Bug 48647 has been marked as a duplicate of this bug. ***
looks like chunked upload issue
Recent report of the problem (with not much more information and in Russian, though): https://commons.wikimedia.org/w/index.php?title=Commons:Upload_Wizard_feedback&oldid=106815121#Fehlermeldung
For the record, since I had to grep the feedback page for it, the Russian comment dating September 24th 2013 just states that they've encountered the error, nothing more.
I confirm that this is probably coming from chunked upload-specific APIs. More specifically "checkStatus", which allows to check when an upload has been reassembled when the chunk API keeps replying "Poll". It seems like something almost identical is also exposed to API consumers through "statuskey", but UploadWizard doesn't seem to make use of it. The failure is due to the session entry for the requested filekey being missing. I will investigate further once I have shell access approved to access logs. Something I'm particularly interested in finding out is whether all the session data is missing or just the entry for the particular file we're interested in.
Just got this on https://commons.wikimedia.org/wiki/File:Practica_D._magistri_V00241_00000004.tif Error console says the following, dunno if related: 2 Validation error against schema UploadWizardFlowEvent: Unrecognized property: quantity 8 Failed to load resource: the server responded with a status of 503 (Service Unavailable) https://commons.wikimedia.org/wiki/Special:UploadStash/thumb/12mniz1s4dlw.l7rnkh.4135183.tif/lossy-page1-78px-12mniz1s4dlw.l7rnkh.4135183.tif.jpg
(In reply to Gilles Dubuc from comment #9) > I confirm that this is probably coming from chunked upload-specific APIs. > More specifically "checkStatus", which allows to check when an upload has > been reassembled when the chunk API keeps replying "Poll". > > It seems like something almost identical is also exposed to API consumers > through "statuskey", but UploadWizard doesn't seem to make use of it. > > The failure is due to the session entry for the requested filekey being > missing. I will investigate further once I have shell access approved to > access logs. Something I'm particularly interested in finding out is whether > all the session data is missing or just the entry for the particular file > we're interested in. Is this a sudden increase? If so, maybe hhvm related? chunked upload does some scary stuff with sessions, it wouldn't shock me if hhvm interfered with that somehow.
I'm adding HHVM to the keywords, just in case.
