@bd808 I remember now. Thanks for reminding me.

@bd808 Thank you! I have started using the Mediawiki REST API instead (see https://phabricator.wikimedia.org/T369414#9958156), using e.g. https://en.wikipedia.org/w/rest.php/v1/page/MediaWiki:Spam-blacklist, which works fine as well.

In T369414#9958164, @Bugreporter wrote:

when using curl, please specify a custom user agent.

Using the Mediawiki REST API works good enough. So this is not that urgent for me anymore.

I haven't checked if this applies to _all_ action=raw requests.

It seems btmwiki is not yet in meta_p.

Thanks a lot!

Another one:
https://meta.wikimedia.org/w/index.php?userExpLevel=unregistered%3Bnewcomer&hidebots=1&hidecategorization=1&hideWikibase=1&hidelog=1&hidenewuserlog=1&namespace=1198&invert=1&tagfilter=mw-reverted&inverttags=1&limit=50&days=7&title=Special:RecentChanges&urlversion=2

In T366256#9845741, @Aklapper wrote:

Note that the infobox shows

Does not happen here. https://de.wikipedia.org/api/rest_v1/page/mobile-html/Adam_Wharton shows 6. Februar 2004.

Triaging as high since vandalism was visible in the app over days.

toolforge jobs store file sounds good.

Not sure what happened but for some reason the file is gone now.

Seems similar to T357098.

Works perfectly, thank you!

The banner says 8:30 to 8:40 UTC. I was confused that it was still there.

Back then it wasn't possible due to the peculiarities of the Rust buildpack, but now that I have restructured it to be a Rust "workspace" I will give it another shot.

In T355231#9468882, @taavi wrote:

Is there a task for supporting that?

Unfortunately I can't use the Build Service since https://gitlab.wikimedia.org/countcount/xlinks is a monorepo for both the xlinks data collector and the spamcheck webapp. AFAICS the Multi Procfile buildpack is not supported.

It is unfortunately not coming back.

The golang1.11 webservice image is on Debian buster. The jdk17 webservice image is on bullseye:

tools.spamcheck@tools-sgebastion-10:~$ cat service.template
backend: kubernetes
type: jdk17
extra_args:
  - ./run.sh
tools.spamcheck@tools-sgebastion-10:~$ kubectl exec -it spamcheck-<redacted> -- /bin/bash
tools.spamcheck@spamcheck-<redacted>:~$ cat /etc/debian_version
11.8

If there is any bookworm-based image I can use with a binary, please let me know.

OK, I opened T355231.

@taavi Is there a separate task for the webservice images?

Oversight on my part, should be fixed now. Please confirm.

@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.