This feature has been removed.

Thanks! The bots are now indeed back.

the In the news section still starts with July 31. Not sure what's up with that.

This morning (CEST), I visited my favorite wiki's main page and was shown a cached version from yesterday (2024-07-31). So I took a snapshot of the debug comment:

<!-- 
NewPP limit report
Parsed by mw‐web.eqiad.main‐5ffbbd4f55‐hlpc7
Cached time: 20240731111040
Cache expiry: 3600
Reduced expiry: true
Complications: [no‐toc]
CPU time usage: 0.345 seconds
Real time usage: 0.468 seconds
Preprocessor visited node count: 4056/1000000
Post‐expand include size: 53226/2097152 bytes
Template argument size: 13576/2097152 bytes
Highest expansion depth: 15/100
Expensive parser function count: 16/500
Unstrip recursion depth: 0/20
Unstrip post‐expand size: 2104/5000000 bytes
Lua time usage: 0.060/10.000 seconds
Lua memory usage: 1460527/52428800 bytes
Number of Wikibase entities loaded: 0/400
-->
<!--
Transclusion expansion time report (%,ms,calls,template)
100.00%  276.223      1 -total
 80.62%  222.704      1 Šablona:Nejnovější_aktuality
 39.88%  110.165     11 Šablona:Aktualita_úmrtí
 38.10%  105.249     11 Šablona:Aktualita_úmrtí/výstup
 28.34%   78.286      8 Šablona:Aktualita
 25.48%   70.372     15 Šablona:Flagicon
 18.04%   49.819     22 Šablona:Delink
 10.09%   27.877      1 Šablona:Nejnovější_aktuality/Box_s_odkazy
  9.31%   25.713      1 Šablona:Vseznam
  8.73%   24.119     15 Šablona:Flagicon/core
-->

In T367638#10023959, @Wargo wrote:

In T367638#10022975, @matej_suchanek wrote:

If we cannot assume the user exists locally, what should be done?

Or some interwiki pointing. The action is done using account on external wiki, so that account should be linked anyway. To be handled by CentralAuth and their hooks?

It seems two problems meet here:

Could it be accounts created by email? I.e. log_action = 'byemail'. Or log_action = 'create2', too.
In these cases, the actor is the user who creates the account, not the account created.
Try query for log_namespace = 2 AND log_title = REPLACE(user_name, ' ', '_') instead.

In T303433#10017793, @kostajh wrote:

In T303433#9980959, @matej_suchanek wrote:

Yes, every change to a filter in fact resets its throttled status.

But let me make one thing more clear. Now, only "local filters" are actually throttled. A global filter is considered "local" only for metawiki. Not sure if this is a bug or feature, anyway this is how it works right now.

If I understand correctly, this means that if someone create a global filter on metawiki to show a CAPTCHA for all edits, and this filter is triggered on e.g. enwiki, then the creator of the filter will receive the "throttle notification" whenever this limit is reached on enwiki?

Yes, every change to a filter in fact resets its throttled status.

This has recently again become an attack vector for abuse, so I'm reviving this task.

T368203: Abuse filters with array index access cannot be saved anymore: "MediaWiki\Extension\AbuseFilter\Parser\Exception\UserVisibleException: notarray" should be fixed in wmf.13, yet you report wmf.12.

In T303433#9971774, @JJMC89 wrote:

Rate limiting those notifications (maybe max 1/filter/hour?) or being able to disable them would allow us to decline this task.

In T307828#7911251, @matej_suchanek wrote:

But CentralAuthForcedLocalCreationService::attemptAutoCreateLocalUserFromName cannot pass the authority further because neither CentralAuthUtilityService::autoCreateUser nor AuthManager::autoCreateUser support that.

In T368203#9916180, @suffusion_of_yellow wrote:

Brainstorming here, but if all we're interested in is the names of any variables that might be used, is it really necessary to evaluate the filter? Maybe just extract the names from AbuseFilterTokenizer's output instead?

Having reproduced locally, I found it is this exception. The type is null (no variable has a value). Maybe it should handle DNULL in the same way as DUNDEFINED?

T307827 mentions AF194, too. So I think it is the same problem.

Down to 1038: https://performance.wikimedia.org/xhgui/run/view?id=66730ec0d13d323f52dc193f. (Note that the count may be different for different users and may change over time as the original link is not permanent.)

In T367463#9894557, @Jdlrobson wrote:

Out of curiosity, why are all those images linked e.g. wrapped in A tags (in comparison to https://en.wikipedia.org/wiki/Template:Routemap) - is there an on-wiki reason?
(Please also see the NOTE at the top of the task for a temporary workaround)

In T367172#9887402, @Jeff_G wrote:

Why is experience level important when displaying watchlist?

Something like https://commons.wikimedia.org/wiki/Special:ApiSandbox#action=watch&format=json&unwatch=1&generator=watchlistraw&formatversion=2&gwrnamespace=6&gwrlimit=500 can remove them in batches (of 500).

It was probably copypasted nonsense from the beginning because cleanupUsersWithNoId.php would clean up only core tables...

In T367144#9883492, @Ladsgroup wrote:

Fixed commons. Let's see what's next.

I'm still super confused, but I think the corruptions might be related to RenameUser. AbuseFilter did not support RenameUser until 65708afcea842c696726883ab3c13f75cf5066bb, so old af(h)_user_text are still in the database. Maybe the maintenance script is complaining because of this? Also, if there was a database import, the renamed users wouldn't propagate from prod to beta, right?

@Ladsgroup would report similar errors on the first run: T336224#8838909.

It would be good to know something about the query plan and also about your watchlist. I noticed the URL includes namespace=6. What portion of your watchlist are files?

Steps to reproduce:

This task mixes two kinds of things.
-withoutinterwiki corresponds to https://en.wikipedia.org/wiki/Special:WithoutInterwiki. It is not a filter, it is a generator. Let's not touch that argument.
-ns(:not) and -titleregex(not) are filters. There is also -grep(not) and -onlyif(not). If anything, these should be unified.

Unfortunately, no one has come up (proposed) with a reasonable solution that would 1) be non-confusing, 2) unambiguous, 3) and cover all edge cases.
For example, you might need to undo a sequence of 10 edits, each made by a different user. Do we want to name them all? (What about the edit comment length limit?)
Or, how to indicate the span of undone revisions in a clean, yet compact way?

Fair point, renamed.

I have been running into these lately, too. Especially when calling DataSite.loadrevisions.

I decided to start over and small.

In T363906#9765595, @Tchanders wrote:

This could be captured by changing af_hidden from a bool to a bitfield, and should be fairly backwards compatible if public=0 and private=1.