The auto-throttling mechanism disabled dangerous action for a given filter if it matches x% of at least the last y edits, if the filter was modified in the last day. The default values (both inside AF's extension.json and wmf-config) are x=5 and y=2. While x is fine, y sounds like a bit too low. My proposal is to increase it to at least 5 actions, both in AF and for WMF production.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Restricted Task | |||||
| Open | None | T302151 Emergency disable improvements | |||
| Resolved | Daimona | T200036 Filters shown as throttled on Special:AbuseFilter even without throttled action | |||
| Open | None | T183099 Provide a button for quickly reactivating filters | |||
| Open | None | T210151 Emergency disable action count may be too low | |||
| Resolved | matej_suchanek | T264629 Use independent stats for emergency disable |
Event Timeline
Comment Actions
I misunderstood the docs. The actual meaning is "[...] if it matches more than x edits, consituting more than y% of the last edits". This makes sense, and I also updated the docs in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/475336/.
Comment Actions
I'm going to be bold and reopen this bug. I've created the section Emergency throttling explaining how it works, and also how can a filter be randomly disabled, just because 2 edits hit the filter close after the number of profiling action reaches $wgAbuseFilterProfileActionsCap.
Raising the value of $wgAbuseFilterEmergencyDisableCount would lower the chances that a filter gets falsely tagged as "dangerous" and then disabled. (I've already set it to a higher value on my wiki after being hit by this problem)
Comment Actions
@Ciencia_Al_Poder Thanks. Just to be clear, only dangerous actions are disabled, and I've updated the docs accordingly.
Yes, this is bad design. I had already noticed it, and left a @todo somewhere in the code, probably in a patch which is still under review. I believe the proper solution would be to evict older values when we reach the cap (LRU-style), instead of resetting to 0. This way we'd avoid spikes and unlucky coincidences. Although I'm unsure whether it could have any impact on performance.
As for tweaking the settings, what values would you propose?
Comment Actions
I've raised it to 10, but I can't say whether it's a sensible default value... Maybe 5?
Comment Actions
What about measuring the shutdown treshold per user, so it would be like "a lot of users are facing difficulties"? That way, we would be more safe with one-man-shutdowns? What do you think?