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.

Is this still a problem/still happening? If not, maybe this tasks priority could be lowered or declined or something?

In T45967#1267485, @Josve05a wrote:

Is this still a problem/still happening? If not, maybe this tasks priority could be lowered or declined or something?

There is no specific reason to believe something may have fixed this since December, AFAIK. I don't know if errors are still being logged somewhere.