| Davey2010 | |
| Mar 11 2020, 8:29 PM |
| F31677025: wmf cmns error.png | |
| Mar 11 2020, 8:29 PM |
Hi, Whenever I use the "Upload a new version of this file" feature on Commons I keep getting the WMF error message, The uploading percentage varies and can error on 99%,
After the fifth attempt at uploading it tends to then upload but just lately it seems that on every file revision upload it has take 5 attempts or more for it to upload,
Many thanks,
Regards,
Dave
Hi @Davey2010,
does anything relevant appear in your browser's "console" and/or "network" tab when this happens? For more information please see:
Which browser is this about? Does this also happen with other browsers?
Unfortunately closing this Phabricator task as no further information has been provided.
@Davey2010: After you have provided the information asked for and if this still happens, please set the status of this task back to "Open" via the Add Action... → Change Status dropdown. Thanks!
Hello, @Aklapper.
I'm also seeing the "Wikimedia Error" page every time I try to use the "Upload a new version of this file page". I've tried seven or eight times today, including a break of several hours, and still cannot get a 36MiB file to upload successfully.
The exact error is:
Request from - via cp3052.esams.wmnet, ATS/8.0.8 Error: 502, Server Hangup at 2020-09-27 18:37:09 GMT
The Firefox "Network" tab shows a POST request which lasts for 205710ms and receives as a response body this "Wikimedia Error" page, with response headers (seemingly with an undefined HTTP status code):
undefined undefined undefined date: Sun, 27 Sep 2020 18:40:34 GMT server: ATS/8.0.8 cache-control: no-store content-type: text/html content-language: en content-length: 1760 X-Firefox-Spdy: h2
The console shows no errors at all on the "Wikimedia Error" page, but on first loading the "Upload file" page the console shows the following warnings:
Any idea why every attempt to upload a replacement file is failing like this? Using the standard uploader for new files has worked fine in the last few days, as has the Wiki Loves Monuments uploader.
As an additional note: I resolved the "Request to access cookie or storage . . . was blocked" warning by turning off Enhanced Tracking Protections in Firefox, but exactly the same thing happens: several minutes pass before this "Wikimedia Error" page appears with "502, Server Hangup" failure.
Is everyone else able to upload replacement files for existing images? I'm trying to upload an improved version of an image for a Featured Picture review, but the uploader seems to make it impossible.
Also, to rule out the web browser, I installed Midori and, using its default configuration, visited the "Upload a new version of this file" page and tried the same thing. This time the end result was that Midori reported that the Wikimedia Commons page could not be found. So again failure.
Could there be something about the JPEG file that is causing the Wikimedia software to choke?
More info: the "Upload a new version of this file" page worked fine with a different image, of 15MiB in size. But immediately afterwards an attempt to upload the 36MiB file failed with the same old error. So I'm guessing it's one of these three causes:
Spotted that the metadata included the name 'Flückiger" and that the umlaut was causing a character encoding problem in IPTC and EXIF metadata, so replaced that with an ASCII 'u' character, and reattempted upload. Still fails.
So I'm at a loss to explain why this particular JPEG file causes Wikimedia to throw a "Server Hangup" error.
I have the same problem as Bobulous and others.
When I try to upload a djvu file thanks to this page https://commons.wikimedia.org/wiki/Special:Upload, I get an error message :
Request from - via cp3052.esams.wmnet, ATS/8.0.8 Error: 502, Server Hangup at 2020-10-10 09:20:19 GMT
I tried to use commonist 1.10.0 either, and here is error log :
INFO [2020-10-10T08:55:58.373Z] UploadFilesTask.scala:84 logging in
DEBUG [2020-10-10T08:55:58.398Z] Connection.scala:120 POST https://commons.wikimedia.org/w/api.php HTTP/1.1
oct. 10, 2020 10:55:58 AM org.apache.http.client.protocol.ResponseProcessCookies processCookies
AVERTISSEMENT: Invalid cookie header: "Set-Cookie: WMF-Last-Access=10-Oct-2020;Path=/;HttpOnly;secure;Expires=Wed, 11 Nov 2020 00:00:00 GMT". Invalid 'expires' attribute: Wed, 11 Nov 2020 00:00:00 GMT
DEBUG [2020-10-10T08:55:58.970Z] Connection.scala:123 HTTP/1.1 200 OK
DEBUG [2020-10-10T08:55:58.976Z] Connection.scala:120 POST https://commons.wikimedia.org/w/api.php HTTP/1.1
oct. 10, 2020 10:56:00 AM org.apache.http.client.protocol.ResponseProcessCookies processCookies
AVERTISSEMENT: Invalid cookie header: "Set-Cookie: WMF-Last-Access=10-Oct-2020;Path=/;HttpOnly;secure;Expires=Wed, 11 Nov 2020 00:00:00 GMT". Invalid 'expires' attribute: Wed, 11 Nov 2020 00:00:00 GMT
DEBUG [2020-10-10T08:56:00.860Z] Connection.scala:123 HTTP/1.1 200 OK
INFO [2020-10-10T08:56:00.861Z] UploadFilesTask.scala:91 login successful Hector
INFO [2020-10-10T08:56:00.863Z] UploadFilesTask.scala:111 uploading files
WARN [2020-10-10T08:56:00.863Z] Parser.scala:38 could not parse coordinates
DEBUG [2020-10-10T08:56:00.965Z] Connection.scala:120 POST https://commons.wikimedia.org/w/api.php HTTP/1.1
oct. 10, 2020 10:56:01 AM org.apache.http.client.protocol.ResponseProcessCookies processCookies
AVERTISSEMENT: Invalid cookie header: "Set-Cookie: WMF-Last-Access=10-Oct-2020;Path=/;HttpOnly;secure;Expires=Wed, 11 Nov 2020 00:00:00 GMT". Invalid 'expires' attribute: Wed, 11 Nov 2020 00:00:00 GMT
DEBUG [2020-10-10T08:56:01.367Z] Connection.scala:123 HTTP/1.1 200 OK
DEBUG [2020-10-10T08:56:01.372Z] Connection.scala:120 POST https://commons.wikimedia.org/w/api.php HTTP/1.1
oct. 10, 2020 10:59:29 AM org.apache.http.impl.execchain.RetryExec execute
INFOS: I/O exception (java.net.SocketException) caught when processing request to {s}->https://commons.wikimedia.org:443: Connexion ré-initialisée par le correspondant (Write failed)
oct. 10, 2020 10:59:29 AM org.apache.http.impl.execchain.RetryExec execute
INFOS: Retrying request to {s}->https://commons.wikimedia.org:443
oct. 10, 2020 11:02:58 AM org.apache.http.impl.execchain.RetryExec execute
INFOS: I/O exception (java.net.SocketException) caught when processing request to {s}->https://commons.wikimedia.org:443: Relais brisé (pipe) (Write failed)
oct. 10, 2020 11:02:58 AM org.apache.http.impl.execchain.RetryExec execute
INFOS: Retrying request to {s}->https://commons.wikimedia.org:443
oct. 10, 2020 11:06:27 AM org.apache.http.impl.execchain.RetryExec execute
INFOS: I/O exception (java.net.SocketException) caught when processing request to {s}->https://commons.wikimedia.org:443: Connexion ré-initialisée par le correspondant (Write failed)
oct. 10, 2020 11:06:27 AM org.apache.http.impl.execchain.RetryExec execute
INFOS: Retrying request to {s}->https://commons.wikimedia.org:443
ERROR [2020-10-10T09:09:54.764Z] UploadFilesTask.scala:70 upload task errorThanks for your help !
The error comes from the server. Thus, I don't think the browser's error console would be much helpful here. I guess this kind of error might get logged somewhere on production, hence tagging Wikimedia-production-error
This is afaik not an error code that MediaWiki can emit, but something from a middle layer between MediaWiki and the Varnish frontend that serves the error, e.g. ats-backend, or appserver envoy-tls, or Apache, or php-fpm.
I have seen a few similar complaints in the past, always on a moderately-sized file (nowhere near 100MiB) and with someone on a slower connection. I've never been able to reproduce the issue with software throttling (it either works or I time out before the upload does). As a workaround, you should be able to use https://commons.wikimedia.org/wiki/User_talk:Rillke/bigChunkedUpload.js to upload new versions as chunked uploads. Because the chunks are smaller, they are less susceptible to network issues and timeout problems.
I looked through my IRC logs and found the most recent complaint: a 7.5 MiB API upload with the error
Request from - via cp3058.esams.wmnet, ATS/8.0.7 Error: 502, Server Hangup at 2020-06-24 18:23:02 GMT
That user was connected to IRC over a Hurricane Electric IPv6 Tunnel Broker, and was eventually able to upload the image after multiple retries.
@Davey2010 also reported a new occurrence of this problem at https://commons.wikimedia.org/wiki/Commons:Village_pump/Technical#Error%3A_502%2C_Server_Hangup.
I think it's important to note that all the reported errors are from esams.
To @AntiCompositeNumber. As someone who regularly encounters this type of problem, your advice on bigChunkedUpload is very fine. It works. But it baffles me that you are not able to simulate a slow internet connection, so you can actually experience the problems yourself. What does it mean "I time out before the upload does". There should be a setting in the software to give you more time, so you can finally see for yourself what other users are up against. Cheers.