I'm unable to reproduce this locally. When I attempt to upload a file that triggers UploadBase::verifyMimeType() to return 'filetype-bad-ie-mime' as an error, it does not include the parsed output of the error message:

{
   "error" : {
      "code" : "verification-error",
      "info" : "This file did not pass file verification: Unknown error: \"filetype-bad-ie-mime\"",
      "details" : [
         "filetype-bad-ie-mime",
         "foo"
      ],
      "*" : "See http://localhost/w/api.php for API usage"
   }
}

Chunked upload gives a somewhat less useful message, but still not what's reported here:

{
   "error" : {
      "code" : "stashfailed",
      "info" : "filetype-bad-ie-mime",
      "*" : "See http://localhost/w/api.php for API usage"
   }
}

I did the upload through pywikibot but checked and the message did not originate from there.

@Lokal_Profil Can you upload the problematic file here to Phabricator? (Use the icon on the comment field toolbar.)

It would also be useful to know the exact version of pywikibot you're using, the exact command you're running, and the exact complete output.

API action=upload can return a "stashfailed" in approximately a billion different circumstances in one of its million different modes, and it's possible one of them handles the output incorrectly and outputs this (broken) message rather than an error code. But it's far easier for you to give us more details, so that we can tell which one you're running into, than for us to try to check them all.

In T147720#2707196, @matmarex wrote:

It would also be useful to know the exact version of pywikibot you're using, the exact command you're running, and the exact complete output.

@Lokal_Profil: Could you provide this? ^

Appologies for the delay.

Pywikibot: I'm using the master/dev branch where I call the pywikibot.Site.upload() method.

I'll check if I still have the original error log (and the failing file) on the external drive provided by the GLAM. Note though that the file might be ~100MB.

In T147720#2756213, @Lokal_Profil wrote:

Appologies for the delay.

Pywikibot: I'm using the master/dev branch where I call the pywikibot.Site.upload() method.

I'll check if I still have the original error log (and the failing file) on the external drive provided by the GLAM. Note though that the file might be ~100MB.

I've just checked the external disk and unfortunately I haven't kept the log files so I cannot give you a closer explanation of the source of the error. My hope was that it would be possible to grep for the string in the appropriate repo.

Note that rMW4e6810e4a2c1: API: i18n for warnings and errors (which should be deployed with 1.29.0-wmf.6) probably changed whatever code was giving you the issue.

My first thought would be to upload the file to Phab. It would also be helpful if you would post a full script that can be run to reproduce the error.

The following script is the minimal implementation (tested) which triggers the error (but requires pywikibot).

I could not upload the image to phab since it was to large but I've attached the associated info file (in case that somehow plays a role) and I stuck the image on dropbox.
Fotografi,_katedral_i_Salamanca_-_Hallwylska_museet_-_107303.tif
{F5013004}

Your script and the text of the dropbox link say "Fotografi,_katedral_i_Salamanca_-_Hallwylska_museet_-_107303", but the actual dropbox filename and the info file are "Chatelaine,_1700-tal_-_Hallwylska_museet_-_110501"?

Argh. Jupp that was a file with another upload problem.

Fotografi,_katedral_i_Salamanca_-_Hallwylska_museet_-_107303.tif and

An update: Uploading the file via the api with chunked upload turned off does not trigger the error message.

The upload was accidental* but means any testing needs to be done Beta Commons instead (apologies for that).

*I'm trying to get some smaller .tif files mistakenly caught by the "This file contains HTML or script code that may be erroneously interpreted by a web browser." to upload by not chunking them.

I can confirm it now, but it's not an API bug.

To reproduce: Make a chunked upload where one of the chunks after the first fails the IE mime type test.

What happens here is that UploadFromChunks::verifyChunk() is getting the proper error indicator [ 'filetype-bad-ie-mime', 'application/x-msdownload' ] for one of the partial chunks and it's stupidly keeping only the 'filetype-bad-ie-mime' bit because of the incredibly weird way it uses UploadChunkVerificationException. It doesn't happen for non-chunked uploads because those don't even use UploadFromChunks, and if the failure happens for the first chunk (as in T147720#2705921) rather than a subsequent chunk it errors out via a different code path instead.

(The reason why the upload is failing at all is probably T143610. The only workaround is to try to upload in chunks of a different size and hope you don't hit it.)

For future reference (Dropbox links tend to die sooner or later), the problematic file is also available at https://commons.wikimedia.org/wiki/File:Fotografi,_katedral_i_Salamanca_-_Hallwylska_museet_-_107303.tif now.

Change 326944 had a related patch set uploaded (by Bartosz Dziewoński):
Do not lose message parameters in UploadFromChunks::verifyChunk()

https://gerrit.wikimedia.org/r/326944

Change 326944 merged by jenkins-bot:
Do not lose message parameters in UploadFromChunks::verifyChunk()

https://gerrit.wikimedia.org/r/326944