May 11 2021
Could the breakage of the Global User Contributions tool (GUC) be related to this? See T282557.
Mar 19 2021
Mar 5 2021
Feb 17 2021
Jan 29 2021
Adding editor or autoreview rights using the Action API (action=userrights) does not work either, while adding ip-block-exempt using the API works fine, just like what the UI promises.
Nov 6 2020
It would be great for counter-vandalism tools and bots, if those tag changes could be published via the Recent Changes event stream (https://stream.wikimedia.org/v2/stream/recentchange) or another event stream.
Oct 21 2020
Oct 20 2020
Oct 15 2020
AFAICS this happens for everyone who has Advanced mobile contributions enabled.
Sep 20 2020
Can this be triaged as Unbreak now? High profile pages with 1000s of daily views are affected such as https://de.m.wikipedia.org/wiki/Deutschland
Over 50% of page views are now mobile.
Sep 18 2020
@matmarex Looks good today, keeping my fingers crossed.
Sep 17 2020
Was the cache cleared? Here is the next account which was autopromoted despite being blocked:
Sep 16 2020
Sep 15 2020
Thanks for looking into this.
I have written a tool to check the autopromote criteria for dewiki and looked at the autopromotions since it started up again.
Aug 13 2020
Aug 4 2020
Duplicate of T259571?
Seems to affect the mobile interface in all language versions.
Aug 3 2020
Jul 14 2020
This should really have Unbreak now! priority as users/visitors perceive it as a security issue.
Jun 30 2020
Too be honest, I don't really understand why we need special docker images for Rust (or any compiled language for that matter). Cross-compiling works, per-user installation of rustup + jsub seems to work fine as well.
Apr 4 2020
Interesting, this is what I get right now:
$ while [ 1 ]; do curl --verbose https://de.wikipedia.org/wiki/Wikipedia:Technik/Werkstatt 2>&1|egrep -e "< date:|x-cache:|last-modified:|server:"; done < date: Sat, 04 Apr 2020 18:31:49 GMT < server: mw1365.eqiad.wmnet < last-modified: Sat, 04 Apr 2020 13:18:24 GMT < x-cache: cp3052 hit, cp3064 pass < date: Sat, 04 Apr 2020 18:32:15 GMT < server: mw1372.eqiad.wmnet < last-modified: Sat, 04 Apr 2020 13:18:24 GMT < x-cache: cp3060 hit, cp3064 pass < date: Sat, 04 Apr 2020 18:31:49 GMT < server: mw1365.eqiad.wmnet < last-modified: Sat, 04 Apr 2020 13:18:24 GMT < x-cache: cp3052 hit, cp3064 pass < date: Sat, 04 Apr 2020 18:31:37 GMT < server: mw1319.eqiad.wmnet < last-modified: Sat, 04 Apr 2020 13:18:24 GMT < x-cache: cp3054 hit, cp3064 pass
date: Sat, 04 Apr 2020 10:27:00 GMT
last-modified: Sat, 04 Apr 2020 09:46:05 GMT
x-cache: cp3058 miss, cp3058 hit/26
If it happens again, it might be a good idea to check the timestamps and if the same cache machine is involved.
Right now (18:!5 UTC) I have the same problem:
Mar 10 2020
How does that help 3rd party wikis?
... Not at all.
Mar 8 2020
Mar 6 2020
This is not the fault of the sseclient library. It happens if more than a few (don't know the exact limit) connections are made to wikimedia event streaming servers.
Jan 8 2020
Might be related to the severe service degradation right now?
Jan 5 2020
Dec 27 2019
Nov 28 2019
Nov 23 2019
Nov 22 2019
The 17,000 element #switch in https://de.wikipedia.org/wiki/Vorlage:Metadaten_Einwohnerzahl_AT_Ortschaft was the culprit. I transformed it into a nested switch and now it works perfectly. Would it somehow be possible to include profiling data to see where the time is spent in the HTML output? That would make it much easier to track down issues like this.
Nov 21 2019
Nov 14 2019
This feature was just requested again on dewiki (Permalink).
Nov 3 2019
Sep 16 2019
Jul 16 2019
Jul 9 2019
May 3 2019
Sep 21 2018
Aug 2 2018
It looks like this also occurs on enWP, see e.g. https://en.wikipedia.org/w/index.php?title=Bletchley_Park&diff=next&oldid=846802829