@Urbanecm_WMF I checked with one person who had the same problem and it seems better today. But it still takes about 0.5/3 secs on their watchlist:
https://performance.wikimedia.org/excimer/profile/94e38eb4fbe6be9a

Apparently the cdnjs auto-update has been broken for a while, see https://github.com/cdnjs/cdnjs/issues/14263#issuecomment-3800585676

Could we archive the old etherpads to Cloud VPS object storage using something like this: https://github.com/okfn/etherpad-archiver and have a web service on toolforge to display them ready-only?

@dcaro , @DamianZaremba: I can confirm that it works fine now. Thank you both.

Using

filelog-stdout: $TOOL_DATA_DIR/logs/notify.log
filelog-stderr: $TOOL_DATA_DIR/logs/notify.log

works. If that is the new intended behavior then that is fine and we can add this caveat to the documentation.

What do you mean? I have mount: all in the yaml file.

Got the errors too today, three times in a row but the emails were sent.

Assigning to Ladsgroup as discussed here: https://meta.wikimedia.org/wiki/Talk:Spam_blacklist#c-Ladsgroup-20251006153200-Count_Count-20251006075900

This issue blocks the migration of my tools away from file logs. One hour is very low.

The category count is definitely broken today, see e.g. sub categories here all listed as empty when they are not: https://de.wikipedia.org/wiki/Kategorie:Wohngeb%C3%A4ude_in_Niedersachsen

It comes from the DiscussionTools extension CSS:
https://github.com/wikimedia/mediawiki-extensions-DiscussionTools/blob/0b877fba05b8a2d984e84100695196d797ec1bc3/modules/dt.init.less#L358-L360

As a dewiki CU with a technical background I have been quite frustrated with the limitations of Special:Investigate (limited no. of accounts / ips), no adding accounts manually, no widening of IPv6 ranges, no advanced filtering, etc. and have been thinking about writing a better tool for some time. So just like @L235 I would like to have the ability to use the API on dewiki to develop such a tool.

The move log entries are not exactly duplicate, they differ in the associated_rev_id field of the log_params column.

Looks like there are no more instances of fully duplicate entries though, more general quarry query: https://quarry.wmcloud.org/query/93916

They are not only appearing twice, there are actually two entries created in the db, see https://quarry.wmcloud.org/query/93904

This is indeed no longer reproducible.

It needs to be removed from the sitematrix as well. Code which tries to access the associated URL now fails, because the DNS entry has been removed.

This seems to be completely broken as I can't save anything. It also makes a test fail:

❯ cargo test -- tests::api::test_immutable 
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.08s
     Running unittests src/lib.rs (/Users/hans/dev/countcount/mwbot/target/debug/deps/parsoid-2eaed1445b9c5a61)

Ahh, because @doctaxon as oversighter suppressed the username.

I still don't understand why doctaxon is listed as the blocking admin while the block was done by another admin originally.

I did not know about the restriction that the revert has to be marked as patrolled in order for the reverted tag to be applied. After marking the revert as patrolled the reverted edit is properly marked as reverted.

Now at https://gitlab.wikimedia.org/toolforge-repos/stimmberechtigung

Can this be completed? cswikivoyage is still not listed in the meta_p.wiki table while events are being sent out. This causes problems for my spamcheck tool.

There are some native Rust wikitext parsers we could consider as well:

• https://crates.io/crates/parse-wiki-text-2
• https://crates.io/crates/wikitext-parser
• https://crates.io/crates/mediawiki_parser

This works fine with non-cnb images by using commands like this in the job definition:

command: exec ./xlinks.sh # in turn execs the binary

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