@Aklapper To be honest the closing of this issue is less than satisfactory. In 2013 an RFC on meta decided that for the XTools edit counter the same functionality should stay opt in only. The community wishes should be respected.

Can someone run maintain-views for s2?

Would it be possible to not put the Toolforge wiki replica externallinks views out of commission for hours at a time while doing this?

In T343718#9108248, @Ladsgroup wrote:

I ran maintain-views again, is it fixed now?

Is this the reason why the externallinks table of some wikis in the labsdbs replicas cannot be read currently?

@Aklapper Duh, I only checked the READMe file. Thanks!

Could the breakage of the Global User Contributions tool (GUC) be related to this? See T282557.

In T185664#6927669, @Ladsgroup wrote:

• User permission and auto-promote rules, we should introduce a hook for auto-promote in core and use that instead of directly hooking into $wgAutoPromote variable. I haven't checked the user permissions in depth but any suggestion for simplification is more than welcome.

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.

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.

Works again.

AFAICS this happens for everyone who has Advanced mobile contributions enabled.

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.

In T262970#6474965, @Urbanecm wrote:

@matmarex Should we inform admins somehow, or was that done?

@matmarex Looks good today, keeping my fingers crossed.

Was the cache cleared? Here is the next account which was autopromoted despite being blocked:

• https://de.wikipedia.org/wiki/Spezial:Logbuch?type=&user=&page=Benutzer%3AVsler&wpdate=&tagfilter=&subtype=autopromote

@matmarex, @DannyS712 Hmm, weirdly enough at least two users one dewiki automatically got autoreview rights today despite having been blocked before:

• https://de.wikipedia.org/wiki/Spezial:Logbuch?type=&user=&page=Benutzer%3AAsmen&wpdate=&tagfilter=&wpfilters%5B%5D=newusers
• https://de.wikipedia.org/wiki/Spezial:Logbuch?type=&user=&page=Benutzer%3APublikkom&wpdate=&tagfilter=&wpfilters%5B%5D=newusers

In T237191#6464683, @matmarex wrote:

It looks like it doesn't really count the number of checked edits – it counts the number of edits that are not waiting to be checked (in other words, edits not listed on Special:PendingChanges or Special:UnreviewedPages?). This includes edits in namespaces where FlaggedRevs is not enabled, edits that have been reverted, etc.

So I think this works correctly (or at least, in the same way it has worked previously for years, not necessarily how it was documented to work…).

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.

Duplicate of T259571?

Seems to affect the mobile interface in all language versions.

This should really have Unbreak now! priority as users/visitors perceive it as a security issue.

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.

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
server: mw1369.eqiad.wmnet
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:

In T246185#5970945, @DB111 wrote:

• response header age: 9314 backend-timing: D=124214 t=1584303665170785 date: Sun, 15 Mar 2020 20:21:05 GMT

How does that help 3rd party wikis?

... Not at all.

I think we should call onExtensionFunctions() directly at the end of the extension function defined in flaggedrevs.php and remove it from extension.json altogether.

In T181443#5931256, @TheSandDoctor wrote:

I just discovered that rcwatcher.py crashed at some point within the past couple of days. Interesting.

[...]

requests.exceptions.HTTPError: 429 Client Error: Too Many Requests for url: https://stream.wikimedia.org/v2/stream/recentchange

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.

Might be related to the severe service degradation right now?

In T237191#5674066, @DannyS712 wrote:

See also T45031: FlaggedRevs sometimes not autopromoting users when it should (on pl.wikipedia)

In T238843#5686314, @Aklapper wrote:

@Count_Count: Ah, thanks. Makes sense. Could you create a separate task (maybe under MediaWiki-Parser) for this enhancement request, please?

In T238843#5684430, @Aklapper wrote:

In T238843#5684317, @Count_Count wrote:

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.

@Count_Count: The HTML source includes a "Transclusion expansion time report". Could you elaborate what exactly you are missing / want to see?

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.

This feature was just requested again on dewiki (Permalink).

In T237191#5629386, @Masumrezarock100 wrote:

@Count_Count Just out of curiosity, what is the criteria for auto-promotion there? How many edits an user needs to get promoted to autochecked user and editor?

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