In this task, let's create an option on saving an AbuseFilter that will allow the AbuseFilter maintainer to disable notifications for "high rate of matches". This is useful if we know that the high rate of matches is expected (e.g. T20110: Define AbuseFilter consequence to display a CAPTCHA and T372642: Create a "Challenge" type subtype of "Consequence").
Description
Description
Details
Details
Related Changes in Gerrit:
| Subject | Author | Repo | Branch | Lines +/- | |
|---|---|---|---|---|---|
| EchoNotifier: only notify once per throttled filter | Rajveer42 | mediawiki/extensions/AbuseFilter | master | +46 -7 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Restricted Task | |||||
| Open | None | T302151 Emergency disable improvements | |||
| Open | None | T373797 Make it possible to silence "high rate of matches" AbuseFilter notifications |
Event Timeline
Comment Actions
Rate limiting those notifications (maybe max 1/filter/hour?) or being able to disable them would allow us to decline this task.
Yes please - so far I've received 23 notifications/emails for a filter I just emergency-enabled which deliberately matches a large % of edits.
Comment Actions
I had a look at how these notifications are produced, in case it's useful before picking between the two options.
EmergencyWatcher already tries to notify only once: getFiltersToThrottle skips any filter where isThrottled() is true. So 23 notifications for one filter suggests something is defeating that guard rather than the guard being absent.
Two candidates. First, af_throttled = 1 is written in a DeferredUpdates::addUpdate, and notifyForFilter runs in a separate deferred callback. Requests that land before that write commits all see isThrottled() as false, so a burst of matches can queue a burst of notifications from what is really one throttle event. Second, FilterStore line 101 keeps the throttled flag only when the filter is being disabled, so re-enabling a filter clears it. Enabling a broad filter, watching it throttle, and enabling it again will notify each time, which fits the case described here.
If the burst is mostly the first one, then deduplicating would remove most of the pain without any new UI, and the per-filter opt-out could stay scoped to the CAPTCHA case in T303433 where high match rates are genuinely expected. If it is mostly the second, an opt-out is the better fit.
I have not written a test to confirm the race, so treat the first one as a hypothesis. Happy to dig further or take this on if that would help.
Comment Actions
Change #1325929 had a related patch set uploaded (by Rajveer42; author: Rajveer42):
[mediawiki/extensions/AbuseFilter@master] EchoNotifier: only notify once per throttled filter