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.

First, we need to decide which is preferred, i.e., whether the multiline string should be interpreted as with or without the carriage return, or depend on the platform. (I think it's without.)

This is quite easy to do now, but it's unclear whether it's worth it. The usual motivation is to stop storing the username in each row to save storage and make renaming users trivial. The latter doesn't apply here since only user ids are stored for registered users (event_agent_id). The former applies only to events triggered by IPs.
However, soon, IPs will no longer be used to identify users. Writes to event_agent_ip will stop, old entries will persist forever, though.

Looks like there is still that one problem with credentials when running in PAWS:

That explains the "user that does not exist here". The bot is not registered on test.wikipedia.
If you log in to the bot account and visit a page on test.wikipedia.org, I believe it should solve the problem for you.

Your script is apparently making a request to test.wikipedia.org and fails, claiming you don't have an account there. It's not clear to me why.
Assuming you are using Herzi Pinki account (are you?), this is not true.

Not really. You can easily make a recursive rule without regex, like "a" -> "aa".

In T56153#9666401, @Pppery wrote:

Boldly closing as resolved since this appears to have been fixed at some point.

https://test.wikidata.org/w/index.php?title=Q142&action=history shows "1 & 2' in both places. Ditto https://test.wikidata.org/w/index.php?title=Q785&action=history

The code that is responsible for ensuring only one block is applied is here: https://gerrit.wikimedia.org/g/mediawiki/extensions/AbuseFilter/+/1807a077557ec1248b4ef87e46a58db3801d905b/includes/Consequences/ConsequencesExecutor.php#260.

More evidence: there is no recent connection to nowiki in Wikidata.

Idea (kind of compromise): Remove the UserGroupManager::addUserToGroup call from the database updater (SchemaChangesHandler). The user will be created when the extension is installed but will be promoted only if the wiki decides to use the aggressive counter-features.