Page MenuHomePhabricator

Chunked/stashed uploads fail for some pdf and djvu files: "No specifications provided to ArchivedFile constructor."
Closed, ResolvedPublic

Description

UploadWizard fails when uploading pdf files to Commons over the last two weeks, while previously there was no problem with similar files.

  • In the last step UploadWizard fails, showing the small red exclamation sign (!) with error message <api-error-internal_api_error_MWException> (nothing more).
  • Content: multi-volume Dutch war time history made available by NIOD Institute for War, Holocaust and Genocide Studies (Amsterdam)
  • Failed uploads have similar input metadata for UploadWizard, similar to succesfully uploaded files.
  • Removing occasional quote symbols (') from requested file names for Commons did not solve problem

I am wikipedian in "special residence" (short periodes at institutions). Project:
(English, incomplete) https://en.wikipedia.org/wiki/Wikipedia:GLAM/Wikipedians_in_Special_Residence_in_the_Netherlands_2013-2014
(Dutch, complete) https://nl.wikipedia.org/wiki/Wikipedia:GLAM/Wikipedians_in_Special_Residence

Thank you for considering this request,
Kind regards,

Hansmuller User:Hansmuller https://commons.wikimedia.org/wiki/User:Hansmuller

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

This actually means, before If130594410 we didn't notice that we searched for ".pdf" as file key in the filearchive table for duplicate checking and consequently duplicate checking for PDFs? was entirely broken?

For files that are currently affected by this bug, most likely, yes. But keep in mind that not all PDFs seem to be affected here or there is a randomness/timing factor to it.

Dear all,

  • No upload to Commons, but ... alright to Dutch wikipedia

Today i tried again to upload pdf part2 of the multivolume history, file http://loe.niod.knaw.nl/grijswaarden/De-Jong_Koninkrijk_deel-02_Neutraal_zw.pdf
Upload to Commons did not work:

L._de_Jong_-_Het_Koninkrijk_der_Nederlanden_in_de_Tweede_Wereldoorlog_1939-1945_Deel_2_Neutraal.pdf
<api-error-internal_api_error_MWException>

which worked and put the pdf on the Dutch wikipedia:

https://nl.wikipedia.org/wiki/Bestand:L._de_Jong_-_Het_Koninkrijk_der_Nederlanden_in_de_Tweede_Wereldoorlog_1939-1945_Deel_2_Neutraal.pdf

I hope this gives you a clue.

Thanks, hansmuller

PS With https://tools.wmflabs.org/commonshelper/ i have now a clumsy workaround to get it to https://commons.wikimedia.org/wiki/File:L._de_Jong_-_Het_Koninkrijk_der_Nederlanden_in_de_Tweede_Wereldoorlog_1939-1945_Deel_2_Neutraal.pdf. Still many pdf's to go.

URL2Commons (http://tools.wmflabs.org/url2commons/index.html) seems a better workaround, because in this case URL's re available for download. However, after say 15 uploads, URL2Commons gives error message:

ERROR: null

Perhaps the source website resists many uploads this way.
Cheers, hansmuller

I'm getting the very same error on all possible upload metods (url2commons, Special:UploadWizard, User:Rillke/bigChunkedUpload.js, Special:UploadStash+MediaWiki:EnhancedStash.js) for circa of two weeks.

At this momment the file that I'm attempting to upload isn't public available (per privacy issues, since the url2commons didn't worked, I've taken it offline).

But if I go to
https://commons.wikimedia.org/wiki/Special:UploadStash/file/134ko3bmt0y4.y868w0.12252.pdf
I got the error message:

"Internal Server Error
Cannot serve a file larger than 1048576 bytes."

Maybe this is just shamefully another simple config conflict issue that no paid staffer gives a clue to look at it?

Sorry for being upset, but neither on 2004-2005 I got so many error messages on every and single attempt to donate my free time to WMF (at that time there was only 2 paid tech guys; currently are dozens but no ones appear to be busy on simply keeping the stuff running as it was before)

In T94562#1254143, @555 wrote:

I'm getting the very same error on all possible upload metods (url2commons, Special:UploadWizard, User:Rillke/bigChunkedUpload.js, Special:UploadStash+MediaWiki:EnhancedStash.js) for circa of two weeks.

At this momment the file that I'm attempting to upload isn't public available (per privacy issues, since the url2commons didn't worked, I've taken it offline).

If it's not huge, you can upload it here; just drag the file into the comment box. internal_api_error_MWException is a fairly generic error message, there is no way to tell whether your problem is even remotely related to the one described by Gilles without reproducing it.

But if I go to
https://commons.wikimedia.org/wiki/Special:UploadStash/file/134ko3bmt0y4.y868w0.12252.pdf
I got the error message:

"Internal Server Error
Cannot serve a file larger than 1048576 bytes."

That's T97539; it does not interfere with uploads.

I came across the same problem yesterday, and @MarkTraceur helped me workaround the issue. It's actually quite simple to do, since the files seem to be correctly uploaded to the stash, just not publishable for some reason. Below are his instructions:

Open up your browser console and dump in the snippet with appropriate changes any time you need to manually publish from stash:

var a = new mw.Api(); a.postWithToken( 'edit', { action: 'upload', filekey: '13brcox38pbw.4683no.2012778.pdf', 'filename': 'Congressional_Record_Volume_81_Part_3.pdf' } );

Filekey is the filename that appears in Special:UploadStash, and Filename is the desired filename.

:c:MediaWiki:EnhancedStash.js was unable to deal with this upload because MediaWiki-WMF took too long to respond. It is configured to abort after 2 minutes, in which the query for metadata did not finish. Presumably because the PDF consists of heavy text metadata.

How is this issue related to <api-error-internal_api_error_MWException> -- did you get such a message anywhere, @waldyrious?

How is this issue related to <api-error-internal_api_error_MWException> -- did you get such a message anywhere, @waldyrious?

Yes, I did. That was the original issue I got with this file, when I tried uploading it with UploadWizard. I got the same error as @Hansmuller describes above, i.e. the upload went well till the end, I progressed to the step of filling in the metadata info (description, license, categories, etc) and at the final step (publishing), I got the <api-error-internal_api_error_MWException>:

UW error.png (588×1 px, 49 KB)

Only after that I tried to fix the problem with Special:UploadStash+EnhancedStash.js (resulting in the report which which I assume is what you mean when you say "this issue"), and all the other tools @555 mentions above, to no avail. (Particularly, with bigChunkedUpload.js, I got a puzzling error which I reported in your talk page.)

Hi all,

I am running into problems also. I tried, chunked upload directly, also using URL2 Commons and Rillke's code. I couldn't manage to use the MarkTraceur workaround, since I didn't knew how or where to run the script, so here I am reporting the errors I got:

Uncaught Error: Empty or wrong API response.
title=MediaWiki:EnhancedStash.js&action=raw&ctype=text/javascript:438
{"servedby":"mw1201","error":
{"code":"internal_api_error_MWException","info":"[b7e99e43] Exception Caught: No specifications provided to ArchivedFile constructor."}}

or

Error: Empty or wrong API response. {"servedby":"mw1204","error":{"code":"internal_api_error_MWException","info":"[97b50521] Exception Caught: No specifications provided to ArchivedFile constructor."}}

  • Upload Upload a new version of this file (directly from Wikimedia Commons)

413 Request Entity Too Large
nginx/1.9.3

and

DOMException [NS_ERROR_DOM_QUOTA_REACHED: "Persistent storage maximum size reached"
code: 1014
nsresult: 0x805303f6
location: https://commons.wikimedia.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=3vxc1Hwb:176]

  • Using URL2Commons

NS_ERROR_DOM_QUOTA_REACHED: Persistent storage maximum size reached DOMException [NS_ERROR_DOM_QUOTA_REACHED: "Persistent storage maximum size reached"
code: 1014
nsresult: 0x805303f6
location: https://commons.wikimedia.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=3vxc1Hwb:176]

Any clues on how I can manage to upload the files? Thanks a lot!

3BRBS

title=MediaWiki:EnhancedStash.js&action=raw&ctype=text/javascript:438
{"servedby":"mw1201","error":
{"code":"internal_api_error_MWException","info":"[b7e99e43] Exception Caught: No specifications provided to ArchivedFile constructor."}}

The error details here are

2015-08-31 23:19:16 mw1201 commonswiki exception ERROR: [b7e99e43] /w/api.php   MWException from line 145 of /srv/mediawiki/php-1.26wmf20/includes/filerepo/file/ArchivedFile.php: No specifications provided to ArchivedFile constructor. {"exception":"[Exception MWException] (/srv/mediawiki/php-1.26wmf20/includes/filerepo/file/ArchivedFile.php:145) No specifications provided to ArchivedFile constructor.
[stacktrace]
#0 /srv/mediawiki/php-1.26wmf20/includes/upload/UploadBase.php(664): ArchivedFile->__construct(NULL, integer, string, NULL)
#1 /srv/mediawiki/php-1.26wmf20/includes/api/ApiUpload.php(564): UploadBase->checkWarnings()
#2 /srv/mediawiki/php-1.26wmf20/includes/api/ApiUpload.php(129): ApiUpload->getApiWarnings()
#3 /srv/mediawiki/php-1.26wmf20/includes/api/ApiUpload.php(110): ApiUpload->getContextResult()
#4 /srv/mediawiki/php-1.26wmf20/includes/api/ApiMain.php(1093): ApiUpload->execute()
#5 /srv/mediawiki/php-1.26wmf20/includes/api/ApiMain.php(432): ApiMain->executeAction()
#6 /srv/mediawiki/php-1.26wmf20/includes/api/ApiMain.php(405): ApiMain->executeActionWithErrorHandling()
#7 /srv/mediawiki/php-1.26wmf20/api.php(88): ApiMain->execute()
#8 /srv/mediawiki/w/api.php(3): include(string)
#9 {main}
"}

Error: Empty or wrong API response. {"servedby":"mw1204","error":{"code":"internal_api_error_MWException","info":"[97b50521] Exception Caught: No specifications provided to ArchivedFile constructor."}}

Same details, with the exception of timestamp and server.

  • Upload Upload a new version of this file (directly from Wikimedia Commons)

413 Request Entity Too Large
nginx/1.9.3

This error means that you tried to upload too large of a file, and it was caught before it even made it to MediaWiki.

DOMException [NS_ERROR_DOM_QUOTA_REACHED: "Persistent storage maximum size reached"
code: 1014
nsresult: 0x805303f6
location: https://commons.wikimedia.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=3vxc1Hwb:176]

This is your browser complaining that its DOM storage is filled up, and has to do with JavaScript (in UploadWizard or elsewhere) rather than anything directly to do with the uploading.

NS_ERROR_DOM_QUOTA_REACHED: Persistent storage maximum size reached DOMException [NS_ERROR_DOM_QUOTA_REACHED: "Persistent storage maximum size reached"
code: 1014
nsresult: 0x805303f6
location: https://commons.wikimedia.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=3vxc1Hwb:176]

Same as above.

DOMException [NS_ERROR_DOM_QUOTA_REACHED: "Persistent storage maximum size reached"
code: 1014
nsresult: 0x805303f6
location: https://commons.wikimedia.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=3vxc1Hwb:176]

This is your browser complaining that its DOM storage is filled up, and has to do with JavaScript (in UploadWizard or elsewhere) rather than anything directly to do with the uploading.

This is filed as T66721: mw.loader.store should not occupy all of localStorage, by the way.

Something really odd is that the error states that the $sha1 parameter of the constructor was null and not boolean. However I don't see in the code how getTempFileSha1Base36() can return null. In case of failure, it should return false.

It only happens with UploadFromStash, since that overrides getTempFileSha1Base36(). What's going on here seems to be:

  • The entire text of the PDF is being included in the "metadata" that UploadStash keeps.
  • The whole metadata collection gets serialized and stored into the us_props field in the database. But the us_props field is a BLOB, maximum length 65535 bytes. The serialized metadata with all that text can be larger than this, so MySQL silently truncates the value.
  • When UploadStash tries to read the metadata back in, the unserialize fails.
  • And then when UploadFromStash tries to get the sha1 out of the metadata, it gets null back.

Anomie,

Thanks for the detailed explanations, what can I do to workaround this issue, or in another case, are there chances that it might be fixed?

Thanks a lot!

@3BRBS, for uploading a file that's too big to upload in a single request, I don't know if there is a workaround. I'm hoping my discovery of where things are going wrong will help @Gilles or someone to fix it; I'm personally not very familiar with the file-metadata code to know what the best fix might be there.

Workaround is to use Special:Upload which does not use the upload stash. The short-term fix would be to increase the field size. In the long term, we probably want to rethink what to store in the metadata hash (see also T32906).

Anomie renamed this task from UploadWizard fails uploading pdf with error message <api-error-internal_api_error_MWException> to Chunked/stashed uploads fail for some pdf and djvu files: "No specifications provided to ArchivedFile constructor.".Sep 2 2015, 2:26 PM
Anomie added a subscriber: zhuyifei1999.

We previously solved* problems like this by gzipping the data before we put it in the database, see e.g. T53740 about TemplateData.

* Yes, they're technically not solved, but I haven't heard anyone complain about running into the limits anymore.

@Tgr, sorry for asking this, but where can I access the Special:Upload feature, couldn't find it yesterdat. Thanks!

Just type in Special:Upload in the search box.

Thanks, I already tried this option with chunk upload (didn't knew it was the Special:Upload page)... didn't worked. I will retry later, and try to report if I find any errors.

Oki, I tried again without chunk upload. The file that I am uploading is 259 MB, and the declared maximum file size is: 1,000 MB

The log is:

NS_ERROR_DOM_QUOTA_REACHED: Persistent storage maximum size reached DOMException [NS_ERROR_DOM_QUOTA_REACHED: "Persistent storage maximum size reached"
code: 1014
nsresult: 0x805303f6
location: https://es.wikipedia.org/w/load.php?debug=false&lang=es&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=3vxc1Hwb:176]

And having chunk upload activated in the preferences results in:

NS_ERROR_DOM_QUOTA_REACHED: Persistent storage maximum size reached DOMException [NS_ERROR_DOM_QUOTA_REACHED: "Persistent storage maximum size reached"
code: 1014
nsresult: 0x805303f6
location: https://commons.wikimedia.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=Kk41yJbu:176] load.php:177:898

Handler function NM_observeActivity threw an exception: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannelInternal.remoteAddress]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/toolkit/webconsole/network-monitor.js :: NMonResponseHeader :: line 1026" data: no]
Stack: NM
onResponseHeader@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/toolkit/webconsole/network-monitor.js:1026:5
NM_observeActivity@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/toolkit/webconsole/network-monitor.js:712:9
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:82:14
Line: 1026, column: 0 DevToolsUtils.js:58:0
La codificación de caracteres del documento HTML no fue declarada. El documento se mostrará con texto "basura" en algunas configuraciones de navegador si el documento contiene caracteres duera del rango US-ASCII. La codificación de caracteres de la página debe ser declarada en el documento o en el protocolo de transferencia.

Finished by

413 Request Entity Too Large
nginx/1.9.3

I couldn't manage to use the MarkTraceur workaround, since I didn't knew how or where to run the script

I believe most modern browsers open the console if you press the F12 key. That's where you should run the code snippet.

NS_ERROR_DOM_QUOTA_REACHED: Persistent storage maximum size reached DOMException [NS_ERROR_DOM_QUOTA_REACHED: "Persistent storage maximum size reached"

That's completely unrelated; MatmaRex already linked the reason above. Also I don't think it's causing any actual error.

Handler function NM_observeActivity threw an exception: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannelInternal.remoteAddress]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/toolkit/webconsole/network-monitor.js :: NMonResponseHeader :: line 1026" data: no]

That's some kind of browser extension error. Also unlikely to be causing any problems.

413 Request Entity Too Large

The upload limit without chunked upload is 100MB, so that's sort of expected. That's a very unfriendly way to fail though. Are we really leaving it to nginx to handle overly large uploads? I'm sure the browser sends the size up front.

Anyway, you'll have to upload the file with chunked upload but without using the stash. MediaWiki does not provide any user interface to do that; you'll have to use some kind of script. @Rillke used to have one, I think?

@Tgr, I already tried all the methods, this is: URL2Commons, Chunked upload without and with @Rillke script, and publishing from stash, and in the end it just doesn't upload the file (a .PDF). I posted the errors I received before in this thread. I already used all the methods you mention, except for running the code snippet, which would be the @MarkTraceur workaround.

And the Request Entity Too Large should not be expected?, since I am using chunk upload, so there shouldn't be such a message I guess, becasue when uploading from Special:Uploads has, elegible a 1000 MB limit.

Well, if you are using chunked upload, then Request Entity Too Large means that the chunk was too large (since nginx is only involved before the chunks get reassembled).

I runned the code in the snipet (in Firefox the web console is opened pressing Ctrl+Shift+K) and got this:

Code:

var a = new mw.Api(); a.postWithToken( 'edit', { action: 'upload', filekey: '13f4633di2t8.y83cx2.rCICF4439963c90a3.pdf', 'filename': 'BNCL - Operi de hytoriis etatum mundi, ac descriptione urbium (1493).pdf' } );

Result:

Object { state: .Deferred/promise.state(), always: .Deferred/promise.always(), then: .Deferred/promise.then(), promise: .Deferred/promise.promise(), pipe: .Deferred/promise.then(), done: jQuery.Callbacks/self.add(), fail: jQuery.Callbacks/self.add(), progress: jQuery.Callbacks/self.add() }

I runned the code in the snipet (in Firefox the web console is opened pressing Ctrl+Shift+K) and got this:

Unfortunately I can't recall if I ever got feedback in the console saying the upload was completed -- I suspect not. IIRC @MarkTraceur told me it could take a while, so I didn't close the window until after refreshing the file page (in another tab) of the filename I passed to the script showed the file there. Hope that helps.

ps - in Firefox you can still press F12 and then pick the "Console" tab. It's easier than remembering different shortcuts for each browser (Chrome seems to use Ctrl+Shift+J, for instance).

* Yes, they're technically not solved, but I haven't heard anyone complain about running into the limits anymore.

In this case I suspect it would be pretty easy for a file to hit the limit even when gzipped.

* Yes, they're technically not solved, but I haven't heard anyone complain about running into the limits anymore.

In this case I suspect it would be pretty easy for a file to hit the limit even when gzipped.

Hmm, indeed, I didn't realize that there's this much data in there. I just tested with http://loe.niod.knaw.nl/grijswaarden/De-Jong_Koninkrijk_deel-04_eerste-helft_zw.pdf (same file as T94562#1169918):

pdftotext output1303K
gzipped504K
bzipped382K
In T94562#1600679, @Tgr wrote:

Anyway, you'll have to upload the file with chunked upload but without using the stash. MediaWiki does not provide any user interface to do that; you'll have to use some kind of script. @Rillke used to have one, I think?

It's also using the stash but I might be able adding a switch to disable the stashing step, if this is possible with chunked uploading at all.

T53730#555813, T50700 could be a related errors. Note that a lot has changed since, especially error handling and messages have been improved.

It only happens with UploadFromStash, since that overrides getTempFileSha1Base36(). What's going on here seems to be:

  • The entire text of the PDF is being included in the "metadata" that UploadStash keeps.
  • The whole metadata collection gets serialized and stored into the us_props field in the database. But the us_props field is a BLOB, maximum length 65535 bytes. The serialized metadata with all that text can be larger than this, so MySQL silently truncates the value.
  • When UploadStash tries to read the metadata back in, the unserialize fails.
  • And then when UploadFromStash tries to get the sha1 out of the metadata, it gets null back.

Note that the full-text extraction and delivery is an issue for tools operating on masses of files reading meta data, too. There is no way to exclude metadata from an API requests. Either you get all of them or none. T101400, T32906 are related to this specific issue. Current situation of saving the texts of long documents in the metadata blob doesn't seem to be sensible.

@waldyrious I will try to re-run from a faster internet connection, and actually wait longer to see if the file goes through. Thanks!

Ok, here some updates from running the script in the snippet.

I runned the script from this link: https://commons.wikimedia.org/w/index.php?title=Special:UploadStash&withJS=MediaWiki:EnhancedStash.js

And waited for hour and a half, there is still no result from the upload, I'm pasting the log from the console some lines before I runned the code:

NS_ERROR_DOM_QUOTA_REACHED: Persistent storage maximum size reached DOMException [NS_ERROR_DOM_QUOTA_REACHED: "Persistent storage maximum size reached"
code: 1014
nsresult: 0x805303f6
location: https://commons.wikimedia.org/w/load.php?debug=false&lang=es&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=Kk41yJbu:176] load.php:177:898
stash> render undefined load.php:9:305
stash> unblockPage undefined load.php:9:305
stash> This is not a function! undefined load.php:9:305

var a = new mw.Api(); a.postWithToken( 'edit', { action: 'upload', filekey: '13fhxz9jhec0.rd9yen.rCICF4439963c90a3.pdf', 'filename': 'BNCL - Operi de hytoriis etatum mundi, ac descriptione urbium (1493).pdf' } );
Object { state: .Deferred/promise.state(), always: .Deferred/promise.always(), then: .Deferred/promise.then(), promise: .Deferred/promise.promise(), pipe: .Deferred/promise.then(), done: jQuery.Callbacks/self.add(), fail: jQuery.Callbacks/self.add(), progress: jQuery.Callbacks/self.add() }

No results for this one yet...

Then I clicked on the "publish" blue botton that appears, and runned the code on the console when a windows showing some parameters opens up, here is the complete log I received, sorry if its too long (I probably runned the code more tan once in this page):

Use of "wgAction" is deprecated. Use mw.config instead. load.php:156:550
Use of "wgNamespaceNumber" is deprecated. Use mw.config instead. load.php:156:550
stash> blockPage undefined load.php:9:305
stash> blockPage undefined load.php:9:305
stash> parse undefined load.php:9:305
stash> query undefined load.php:9:305
stash>
query undefined load.php:9:305
Exception in store-localstorage-update: load.php:177:860
NS_ERROR_DOM_QUOTA_REACHED: Persistent storage maximum size reached DOMException [NS_ERROR_DOM_QUOTA_REACHED: "Persistent storage maximum size reached"
code: 1014
nsresult: 0x805303f6
location: https://commons.wikimedia.org/w/load.php?debug=false&lang=es&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=Kk41yJbu:176] load.php:177:898

stash> render undefined load.php:9:305
stash> unblockPage undefined load.php:9:305
stash> This is not a function! undefined load.php:9:305
stash> describe undefined load.php:9:305
stash>
refreshToken undefined load.php:9:305
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:2:685
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:705
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:3177
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:2:6015
Propiedad desconocida 'background-position-x'. Declaración rechazada. index.php:2:6115
Propiedad desconocida '-moz-box-shadow'. Declaración rechazada. index.php:2:7467
Propiedad desconocida '-moz-background-clip'. Declaración rechazada. index.php:2:7589
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:2:9067
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:9087
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:9537
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:2:10341
Propiedad desconocida 'background-position-x'. Declaración rechazada. index.php:2:10401
Se esperaba una declaración, pero se encontró '*'. Ignorado hasta la siguiente declaración. index.php:2:10932
Se esperaba una declaración, pero se encontró '*'. Ignorado hasta la siguiente declaración. index.php:3:2118
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:2:1352
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:1372
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:3611
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:2:6222
Propiedad desconocida '-moz-box-shadow'. Declaración rechazada. index.php:2:6472
Propiedad desconocida '-moz-background-clip'. Declaración rechazada. index.php:2:6594
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:2:8172
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:8192
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:8864
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:2:9892
Se esperaba un 'none', URL, o una función de filtro, pero se encontró 'progid'. Error al interpretar el valor para 'filter'. Declaración rechazada. index.php:2:10389
Error al interpretar el valor para 'background'. Declaración rechazada. index.php:2:10509
Error al interpretar el valor para 'background'. Declaración rechazada. index.php:2:10592
Error al interpretar el valor para 'background'. Declaración rechazada. index.php:2:10701
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:2:12120
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:12140
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:12859
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:2:13936
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:2:14590
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:14610
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:15187
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:2:16120
Exception in store-localstorage-update: load.php:177:860
NS_ERROR_DOM_QUOTA_REACHED: Persistent storage maximum size reached DOMException [NS_ERROR_DOM_QUOTA_REACHED: "Persistent storage maximum size reached"
code: 1014
nsresult: 0x805303f6
location: https://commons.wikimedia.org/w/load.php?debug=false&lang=es&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=Kk41yJbu:176] load.php:177:898

var a = new mw.Api(); a.postWithToken( 'edit', { action: 'upload', filekey: '13fhyvaisadk.wkpsia.rCICF4439963c90a3.pdf', 'filename': 'BNCL - Operi de hytoriis etatum mundi, ac descriptione urbium (1493).pdf' } );
Object { state: .Deferred/promise.state(), always: .Deferred/promise.always(), then: .Deferred/promise.then(), promise: .Deferred/promise.promise(), pipe: .Deferred/promise.then(), done: jQuery.Callbacks/self.add(), fail: jQuery.Callbacks/self.add(), progress: jQuery.Callbacks/self.add() }
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:294
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:405
Se esperaba un 'none', URL, o una función de filtro, pero se encontró 'progid'. Error al interpretar el valor para 'filter'. Declaración rechazada. index.php:2:668
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:894
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:1005
Se esperaba un 'none', URL, o una función de filtro, pero se encontró 'progid'. Error al interpretar el valor para 'filter'. Declaración rechazada. index.php:2:1246
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:1492
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:1603
Se esperaba un 'none', URL, o una función de filtro, pero se encontró 'progid'. Error al interpretar el valor para 'filter'. Declaración rechazada. index.php:2:1844
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:2183
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:2294
Se esperaba un 'none', URL, o una función de filtro, pero se encontró 'progid'. Error al interpretar el valor para 'filter'. Declaración rechazada. index.php:2:2535
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:2812
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:2923
Se esperaba un 'none', URL, o una función de filtro, pero se encontró 'progid'. Error al interpretar el valor para 'filter'. Declaración rechazada. index.php:2:3168
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:3399
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:3510
Se esperaba un 'none', URL, o una función de filtro, pero se encontró 'progid'. Error al interpretar el valor para 'filter'. Declaración rechazada. index.php:2:3730
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:3962
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:4073
Se esperaba un 'none', URL, o una función de filtro, pero se encontró 'progid'. Error al interpretar el valor para 'filter'. Declaración rechazada. index.php:2:4293
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:4667
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:4778
Se esperaba un 'none', URL, o una función de filtro, pero se encontró 'progid'. Error al interpretar el valor para 'filter'. Declaración rechazada. index.php:2:5019
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:5297
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:5408
Se esperaba un 'none', URL, o una función de filtro, pero se encontró 'progid'. Error al interpretar el valor para 'filter'. Declaración rechazada. index.php:2:5653
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:5885
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:5996
Se esperaba un 'none', URL, o una función de filtro, pero se encontró 'progid'. Error al interpretar el valor para 'filter'. Declaración rechazada. index.php:2:6216
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:6449
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:6560
Se esperaba un 'none', URL, o una función de filtro, pero se encontró 'progid'. Error al interpretar el valor para 'filter'. Declaración rechazada. index.php:2:6780
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:7158
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:7269
Se esperaba un 'none', URL, o una función de filtro, pero se encontró 'progid'. Error al interpretar el valor para 'filter'. Declaración rechazada. index.php:2:7510
Error al interpretar el valor para 'background'. Declaración rechazada. index.php:2:79
Error al interpretar el valor para 'background'. Declaración rechazada. index.php:2:162
Error al interpretar el valor para 'background'. Declaración rechazada. index.php:2:271
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:2:967
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:987
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:2:2293
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:2:3949
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:3:1011
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:3:1031
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:3:3442
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:3:6199
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:3:7638
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:3:7658
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:3:10239
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:3:13180
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:3:13993
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:3:14013
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:3:14978
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:3:16285
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:3:18172
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:3:18192
Error al interpretar el valor para 'background-image'. Declaración rechazada. index.php:3:19141
Se esperaba 'importante', pero se encontró 'ie'. Se esperaba un ';' o '}' para terminar la declaración, pero se encontró 'ie'. Declaración rechazada. index.php:3:20434
Exception in store-localstorage-update: load.php:177:860
NS_ERROR_DOM_QUOTA_REACHED: Persistent storage maximum size reached DOMException [NS_ERROR_DOM_QUOTA_REACHED: "Persistent storage maximum size reached"
code: 1014
nsresult: 0x805303f6
location: https://commons.wikimedia.org/w/load.php?debug=false&lang=es&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=Kk41yJbu:176] load.php:177:898

var a = new mw.Api(); a.postWithToken( 'edit', { action: 'upload', filekey: '13fhyvaisadk.wkpsia.rCICF4439963c90a3.pdf', 'filename': 'BNCL - Operi de hytoriis etatum mundi, ac descriptione urbium (1493).pdf' } );
Object { state: .Deferred/promise.state(), always: .Deferred/promise.always(), then: .Deferred/promise.then(), promise: .Deferred/promise.promise(), pipe: .Deferred/promise.then(), done: jQuery.Callbacks/self.add(), fail: jQuery.Callbacks/self.add(), progress: jQuery.Callbacks/self.add() }
stash> __publish undefined load.php:9:305
Use of "ucFirst" is deprecated. load.php:156:550
Error: Empty or wrong API response. {"servedby":"mw1117","error":{"code":"internal_api_error_MWException","info":"[68133535] Exception Caught: No specifications provided to ArchivedFile constructor."}} index.php:438:0
Exception in store-localstorage-update: load.php:177:860
NS_ERROR_DOM_QUOTA_REACHED: Persistent storage maximum size reached DOMException [NS_ERROR_DOM_QUOTA_REACHED: "Persistent storage maximum size reached"
code: 1014
nsresult: 0x805303f6
location: https://commons.wikimedia.org/w/load.php?debug=false&lang=es&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=Kk41yJbu:176] load.php:177:898

var a = new mw.Api(); a.postWithToken( 'edit', { action: 'upload', filekey: '13fhyvaisadk.wkpsia.rCICF4439963c90a3.pdf', 'filename': 'BNCL - Operi de hytoriis etatum mundi, ac descriptione urbium (1493).pdf' } );
Object { state: .Deferred/promise.state(), always: .Deferred/promise.always(), then: .Deferred/promise.then(), promise: .Deferred/promise.promise(), pipe: .Deferred/promise.then(), done: jQuery.Callbacks/self.add(), fail: jQuery.Callbacks/self.add(), progress: jQuery.Callbacks/self.add() }
stash> refreshToken undefined load.php:9:305
stash>
refreshToken undefined load.php:9:305
stash> refreshToken undefined load.php:9:305
stash>
refreshToken undefined load.php:9:305
stash> refreshToken undefined load.php:9:305
stash>
refreshToken undefined load.php:9:305
stash> refreshToken undefined load.php:9:305
stash>
refreshToken undefined load.php:9:305
stash> refreshToken undefined load.php:9:305
stash>
refreshToken undefined load.php:9:305
stash> refreshToken undefined load.php:9:305
stash>
refreshToken undefined load.php:9:305

var a = new mw.Api(); a.postWithToken( 'edit', { action: 'upload', filekey: '13fhyvaisadk.wkpsia.rCICF4439963c90a3.pdf', 'filename': 'BNCL - Operi de hytoriis etatum mundi, ac descriptione urbium (1493).pdf' } );
Object { state: .Deferred/promise.state(), always: .Deferred/promise.always(), then: .Deferred/promise.then(), promise: .Deferred/promise.promise(), pipe: .Deferred/promise.then(), done: jQuery.Callbacks/self.add(), fail: jQuery.Callbacks/self.add(), progress: jQuery.Callbacks/self.add() }

And after several hours, no results for this one either.

Hi all,

I am writing because I asked the National Library if they could redo a PDF file (I guess the word would be re-encode them), to provide a different file, which they did. I tried to do a new upload to Wikimedia Commons, but again failed. Since I tried everything I could, I feel extremely dissapointed that this issue hasn't been fixed, moreover, and this is not techincal, I think it makes Wikimedia Commons look really bad for the institution.

At this point, I would like to ask for someone to help me, either those who know how to run the code in the snipet, if they could try to upload the files as a test, or anybody else that can try to upload this files at all:

Should be uploaded here:
https://commons.wikimedia.org/wiki/File:BNCL_-_Las_Siete_Partidas_%281491%29.pdf

and

Should be uploaded here:
https://commons.wikimedia.org/wiki/File:BNCL_-_Operi_de_hytoriis_etatum_mundi,_ac_descriptione_urbium_%281493%29.pdf

Sorry if this message is not to technical, but my goal is to make this files available, and I feel I did everything I could to make that happen, and I haven´t been able to do so.

Thanks to everybody!

Being bold and adding Lila as subscriber to this 8 months old bug report.

My reasoning is to illustrate that the engineering team of WMF is still failing, despite its large amount of paid staffers (and increasing). Surely there are issues older than this (such de DATA LOSS described on T71311 that occurred one year ago and, as on this report, the solution is known but no action was made), but as far as I know this report is even more relevant, since the WMF may be appearing as an organization with no capable staff, and may be result in lack of future funds and content donations (or even lack of future partnership to do simple outreach actions).

Maybe I look as a scaremonger person due to this action, but the current scenario is really depressing.

Best,
[[User:555]]

@555: Thanks for your comment.
Tasks in Phabricator have a specific technical scope (in this case: chunked uploads failing for PDF and Djvu files).
Meta-level discussions (e.g. on priorities or what WMF in general or WMF staff/teams should do) are best to have on appropriate mailing lists (e.g. multimedia@) or wiki talk pages (mw:Multimedia links to quarterly goals) as per Phabricator etiquette. Thanks a lot for your understanding!

As the first file is 254MB, I enabled Chunked uploads for files over 5 MB in Upload Wizard just to realize that "Upload a new version of this file" on https://commons.wikimedia.org/wiki/File:BNCL_-_Las_Siete_Partidas_%281491%29.pdf opens Special:Upload (which will trigger a HTTP 413 error) instead of Special:UploadWizard. And UploadWizard does not allow overwriting of files. Sigh, so much for trying to reproduce or help out. :-/

Sigh, so much for trying to reproduce or help out. :-/

I think the issue is clear now. Anomie provided a conclusive theory in T94562#1593540. To re-upload files over existing files, you can't use UploadWizard (it simply doesn't support this scenario) and if the file is > a certain limit (last time I checked it was 100 MiB), Special:Upload fails. The only options in this case are "third party tools" like this script.

Well, if that is the case, I think that someone more tech savy could run the code written before to publish from stash. I tried this but I certainly do not know if I am doing it right.

I came across the same problem yesterday, and @MarkTraceur helped me workaround the issue. It's actually quite simple to do, since the files seem to be correctly uploaded to the stash, just not publishable for some reason. Below are his instructions:

Open up your browser console and dump in the snippet with appropriate changes any time you need to manually publish from stash:

var a = new mw.Api(); a.postWithToken( 'edit', { action: 'upload', filekey: '13brcox38pbw.4683no.2012778.pdf', 'filename': 'Congressional_Record_Volume_81_Part_3.pdf' } );

Filekey is the filename that appears in Special:UploadStash, and Filename is the desired filename.

Sadly, I runned the script but it fails when it tries to reassemble/recompose the file (Failed: Succes message).

In T94562#1600679, @Tgr wrote:

Anyway, you'll have to upload the file with chunked upload but without using the stash. MediaWiki does not provide any user interface to do that; you'll have to use some kind of script. @Rillke used to have one, I think?

Added an option to bigChunkedUpload.js -- disable the use stash and async option prior to selecting the file -- Happy uploading!

how could you possibly upload via chunks but not stash?

Hi all,

I am writing because I asked the National Library if they could redo a PDF file (I guess the word would be re-encode them), to provide a different file, which they did. I tried to do a new upload to Wikimedia Commons, but again failed. Since I tried everything I could, I feel extremely dissapointed that this issue hasn't been fixed, moreover, and this is not techincal, I think it makes Wikimedia Commons look really bad for the institution.

For pdf's affected by this bug: Until this bug is fixed, for pdf/djvu files affected by this bug that are > 100 MB, please file a separate bug asking the individual files be uploaded via Server-side uploads (See https://commons.wikimedia.org/wiki/Help:Server-side_upload ). [If you are a gwtoolset user, you can probably work around this bug by using gwtoolset instead]

Change 248637 had a related patch set uploaded (by Brian Wolff):
In UploadStash, prioritize core metadata over file handler metadata

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

@Riilke, thanks a lot for uploading this files!! I really, really appreciate it!

In T94562#1600679, @Tgr wrote:

Anyway, you'll have to upload the file with chunked upload but without using the stash. MediaWiki does not provide any user interface to do that; you'll have to use some kind of script. @Rillke used to have one, I think?

Added an option to bigChunkedUpload.js -- disable the use stash and async option prior to selecting the file -- Happy uploading!

I'm surprised that works. Must be the lack of 'async'. The 'stash' option should be totally ignored when you're doing a chunked upload, so setting/not-setting it should make no difference.

Must be the lack of 'async'.

Confirmed; without the async bit, the known error occurs.

Change 248709 had a related patch set uploaded (by Brian Wolff):
In UploadStash, prioritize core metadata over file handler metadata

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

Change 248637 abandoned by Brian Wolff:
In UploadStash, prioritize core metadata over file handler metadata

Reason:
This was supposed to be submitted to master not 1.27.0-wmf3

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

Change 248709 merged by jenkins-bot:
In UploadStash, prioritize core metadata over file handler metadata

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

Tgr claimed this task.

Verified on beta. Thanks, Bawolff!

Thanks! This change should be deployed to Commons this Wednesday, 28 October 2015, per https://www.mediawiki.org/wiki/MediaWiki_1.27/Roadmap.

@matmarex does that date correspond to the #wmf-deploy-2015-10-27_(1.27.0-wmf.4) tag? I'm asking because it's a day later. If it does, I wonder if the naming scheme of the tag here in Phabricator shouldn't include dates like that, or make it clearer it's the start of a period (maybe something like "wmf-deploy-2015-weekXX" or "wmf-deploy-2015-oct-i", -ii, etc.).

Also note above how the characters used in the tag doesn't allow Phabricator to auto-link it using a # sign, as happens for instance with MW-1.27-release-notes. It might be worth considering a naming change for this reason as well (or submitting a bug report to Phabricator). I know this is sort of off-topic, so feel free to point to where this has been / can be discussed.

Yes. The date in the tag is the date when the branch is created and deployed to the first set of wikis; remaining wikis get the new code over the next two days, as detailed in the table on the page I linked. I don't know about the naming, @greg would know.

Change 201176 abandoned by Gilles:
Add logging to investigate null $hash issue

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

@matmarex does that date correspond to the #wmf-deploy-2015-10-27_(1.27.0-wmf.4) tag? I'm asking because it's a day later. If it does, I wonder if the naming scheme of the tag here in Phabricator shouldn't include dates like that, or make it clearer it's the start of a period (maybe something like "wmf-deploy-2015-weekXX" or "wmf-deploy-2015-oct-i", -ii, etc.).

Also note above how the characters used in the tag doesn't allow Phabricator to auto-link it using a # sign, as happens for instance with MW-1.27-release-notes. It might be worth considering a naming change for this reason as well (or submitting a bug report to Phabricator). I know this is sort of off-topic, so feel free to point to where this has been / can be discussed.

thanks for the suggestions. @matmarex is correct in his explanation for the first part (dates/timing). Regarding naming, if you are so inclined, a task in the ReleaseTaggerBot project outlining the problem and possible solutions would be most welcome. :)