Page MenuHomePhabricator

Abusefilter with block action took no actions
Closed, ResolvedPublicBUG REPORT

Description

https://zh.wikipedia.org/w/index.php?title=Special:%E6%BB%A5%E7%94%A8%E6%97%A5%E5%BF%97&wpSearchUser=KCW7722TTTRRR&uselang=en
See logs at 23:30, 4 March 2022. The user triggered 3 filters in an edit.
The actions for filter 252 is Warn, Block.
Filter 275 is Disallow, Block.
Filter 323 is Warn.
But the log shows filter 275 took "no" actions. I think it should be "block" instead.

Event Timeline

This looks a genuine error, but unfortunately hard to debug because no log entry is written when a block fails. I intend to "fix" this by adding some debug logging in that case, but I'm afraid there isn't much more that can be done, and these "X didn't work on that specific occasion" tasks unfortunately tend to remain open forever without any progress being possible.

@Xiplus As an aside, while I was looking for debug messages related to this, I noticed that zhwiki's filter 340 often fails to run because the regex has horrible performance. Would you be able to take a look? I'd suggest replacing every "match-all dot" with something more specific that guarantees that the regex engine won't try to look ahead until the end of the page. Same for filter 255, which sometimes slows down the page save by a few seconds. (I can provide further guidance on wiki, but unfortunately I don't know what the right place would be). Thanks.

Change 768121 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/AbuseFilter@master] Add logging when the 'block' action fails

https://gerrit.wikimedia.org/r/768121

I logged variable $actionsByFilter, $consequences, $actionsToTake in https://gerrit.wikimedia.org/g/mediawiki/extensions/AbuseFilter/+/a94f71fcac3c53184997d3d18ee057cd8104fdef/includes/Consequences/ConsequencesExecutor.php#90
And I created two filters:
Filter 1: Warn, Block 1 minute
Filter 2: Disallow, Block 1 minute

Then the log shows:
$actionsByFilter = {"1":{"block":["noTalkBlockSet","1 minute","1 minute"],"warn":["abusefilter-warning"]},"2":{"block":["noTalkBlockSet","1 minute","1 minute"],"disallow":["abusefilter-disallowed"]}}
$consequences = {"1":{"warn":{},"block":{}},"2":[]}
$actionsToTake = {"1":{"warn":{}},"2":[]}

Then I set filter 2 to block 2 minute
Then the log shows:
$actionsByFilter = {"1":{"block":["noTalkBlockSet","1 minute","1 minute"],"warn":["abusefilter-warning"]},"2":{"block":["noTalkBlockSet","2 minute","2 minute"],"disallow":["abusefilter-disallowed"]}}
$consequences = {"1":{"warn":{}},"2":{"block":{}}}
$actionsToTake = {"1":{"warn":{}},"2":{"block":{}}}

I think the bug is at replaceArraysWithConsequences function. Hope this information helps.

I can provide further guidance on wiki, but unfortunately I don't know what the right place would be

You can post it on technical village pump https://zh.wikipedia.org/wiki/WP:VPT or my talk page https://zh.wikipedia.org/wiki/User_talk:Xiplus.

Riiiiiight, I forgot to say a few things... First, I tried to reproduce this locally but didn't succeed. I will try again with shorter block durations, since that wasn't part of my experiments. Second, while the patch above is likely useful, it's not related to this specific issue: the AbuseLog entry says "Actions taken: none", which means it didn't even try to block the user: the Block consequence always returns a good status even when unsuccessful. Hence, you'd still have "Actions taken: block" in the AbuseLog if the internal block logic fails.

I can provide further guidance on wiki, but unfortunately I don't know what the right place would be

You can post it on technical village pump https://zh.wikipedia.org/wiki/WP:VPT or my talk page https://zh.wikipedia.org/wiki/User_talk:Xiplus.

Thanks, I'll post at the VPT later.

Change 768228 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/AbuseFilter@master] Refactor ConsequencesExecutor to process consequences in more steps

https://gerrit.wikimedia.org/r/768228

Alright, indeed there was a bug in the consequences logic: we were deduplicating blocks before applying warn and throttle, which could result in us keeping just a block that won't end up being executed. The patch above fixes that (and refactors the relevant code quite a bit).

Daimona triaged this task as High priority.Mar 5 2022, 5:06 PM

Another problem. If a user trigger two filters, first filter block 1 minute with talk access revoked, another filter block 2 minutes only. The result is block 2 minute without talk access revoked. I think it's better to block 2 minutes with talk access revoked.
In a nutshell: If there is any filter is set to revoke talk access. Revoke the talk access no matter what filter is chosen to run.

Change 768121 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@master] Add logging when the 'block' action fails

https://gerrit.wikimedia.org/r/768121

Change 768228 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@master] Refactor ConsequencesExecutor to process consequences in more steps

https://gerrit.wikimedia.org/r/768228