Is this a feature request for an AbuseFilter quick filter reactivate button, or a bug report about some existing AbuseFilter quick filter reactivate button?
Adding a verb to task summaries is always welcome, like "Provide a quick filter reactivate button in AbuseFilter" or such. Thanks :)

Yes, this is a feature request for a button that allows quick reactivation of a disabled filter due to safeguards being exceeded.

In T183099#4199438, @Daimona wrote:

This might be a good reason to provide this feature which wasn't mentioned in the other task. I'll try to see if I can send a patch.

@Daimona Any luck with a patch? An alternative idea is a checkbox to indicate ignoring the threshold throttle limit...Have encounter people deliberately tripping filters just for the sake of it - use case.

A few years later... I think this is actually fairly easy if we're fine with the compromise of not having a filter history entry for the unthrottling. I think perhaps the "this filter is throttled" warning could have a link to remove the restriction, and that would not update the filter age. However, the filter might still get throttled until the 24 hours (or whatever the configured value is) will have passed. IMHO this is also acceptable.

However, the filter might still get throttled until the 24 hours (or whatever the configured value is) will have passed.

Are you saying that this button would reset the filter age, the same as an edit does, or that it might get throttled a second time before the 24 hours since the last "real" edit has occurred have passed? The first seems bad, but the second would be fine.

In T183099#7734360, @RheingoldRiver wrote:

However, the filter might still get throttled until the 24 hours (or whatever the configured value is) will have passed.

Are you saying that this button would reset the filter age, the same as an edit does, or that it might get throttled a second time before the 24 hours since the last "real" edit has occurred have passed? The first seems bad, but the second would be fine.

The second one.

@Daimona Hmm I just thought of an alternative idea/proposal. What if we could on each filter have a checkbox to disable throttling? Instead of having to worry about throttle age, there could be a selection on the specific filter to just ignore throttle conditions.

Sure, a null edit would reactivate but there are the few important ones that should not be disabled. One in mind is a filter to catch bot registration, it can become a mess to untangle or revert.

The risk we run there is that someone may unknowingly (or worse, knowingly) create a relative expensive filter, disable throttling for it, and significantly impact server resources and make editing slower. It'll take a while for people to figure out the cause of such disruption.

@Huji in my above example, it impacts account registration. Overall, that is always a risk and why access to abusefilter should always be strictly limited to only the trusted and those who understand & capable of writing Regular Expressions (regex). Access to abusefilter at WMF is rather strict and chances of that particular risk is low, it seems the risk is for independent third party installs? Those with access to abusefilter and logs should be keeping a regular eye on things and reviewing any new filters created. Access is a privilege of trust and responsibility, all should be acting as a check on each other.

This would not eliminate the max amount of filter conditions though that can be adjusted higher for independent third party installs. This still acts as a countermeasure against the size of a potentially expensive filter.

Sometimes a critical filter being disabled for any amount of time can cause great disruption that may become difficult/time consuming to reverse and having time to immediately perform a null edit may not occur.

That seems like a reasonable option to me, especially if:

1. there were a configurable option like AbuseFilterMaxProhibitDisableDuration (for safety, maybe default it to 1 hour; and setting this to AbuseFilterEmergencyDisableAge effectively makes it unlimited) and
2. disabling throttling on a filter cannot be done at the same time as an edit, but only from the Special:AbuseFilter page (sending you to another confirmation action), so (a) it can't be done by accidentally checking a box or something, and also (b) it will always have its own log entry in Special:Log, helping with debugging

I'm on the fence about that, having such an easily-accessible "ignore all safety features" button sounds like a problem just waiting to happen, even if on WMF it would only be accessible to trusted and knowledgeable people. But it could also be good for filters that have proven to be effective and safe, so long as editors to it are careful (all it takes is one accidental pipe at the end of a regex and suddenly every edit on the wiki is bad).

If such a feature is added though, I'd like to suggest it be added alongside a new user right that's needed to use it.

I think there's some confusion here, a filter cannot be throttled if it's expensive/slow, only if it matches too many actions. Nonetheless, I'm still not convinced that an "ignore all safety features" button is wanted. I think the proper solution would be to 1) implement a button for reactivating a filter like this task proposed, and 2) tweaking the emergency disable params so that it won't trigger this often (T210151).

No confusion here, @Daimona. The point I am making is: if a filter is both making tons of hits AND exempted from throttle, it could be a big deal. Throttling can at least turn it off after a certain number of hits, thereby saving the servers from the stress, and the users from delayed page loads/saves.

@MrPie5 I agree on a new user right to further restrict who can mark a filter exempted from throttle; especially since this allows further protection to avoid malicious actors.

@Huji look I understand your concern and already addressed it above. The point of being able to have a filter be exempted is to ensure its always running and not needing to inform WMF notice boards or admins of independent third party wikis to reactivate a critical filter that exceeded its hit count. A null edit to working filter is literally a pointless action and a waste of time when the filter can just be reactivated when it needs no new changes. If a properly created filter is being tripped too often, that would be indication to increase the consequences from preventing the action -> automatic short block.

Perhaps having the throttle exempt be on Special:AbuseFilter as MrPie5 mentioned instead of the filters themselves could increase confirmation, avoid accidental setting it, and avoid server stress as you are worried about. If everyone who has access to Abusefilter were more proactive in watching filter changes, having the option to reactivate or throttle exempt should be a minor concern. If the team trusts each other and holds each other accountable, this is a non issue. This sounds like a lack of confidence where in WMF's case, the technical skills exist but few are willing to act as check & balance.

@Daimona "implement a button for reactivating a filter" means that upon clicking the button, the filter would be enabled immediately or upon job queue finishing the job. having to wait 24 hours defeats the purpose of the button, especially for a critical filter. At that point, may as well just make a pointless null edit. A null edit works but not everyone has time to do so to avoid massive disruption or clean up later. Easy to mess up on mobile.

Extension:Titleblacklist is not a suitable solution because the regex is public plus if that page gets excessively long may result in server stress since its not checking on specific actions. Another con is that it does not allow blocking such malicious IPs from returning. The built in account creation by IP configuration variable is not effective for those abusing proxies.

In T183099#7762729, @SpookyGhost8 wrote:

The point of being able to have a filter be exempted is to ensure its always running and not needing to inform WMF notice boards or admins of independent third party wikis to reactivate a critical filter that exceeded its hit count.

That point will also be satisfied by having a button that easily re-activates the throttled filter. There is a clear trade-off analysis we should do. The benefit of "exempting" filters is that we don't have to press a button once in a while; the cost is what I described above. The cost of making that "reactivate" button and requiring that a human knowingly clicks it as needed is that a filter may remain throttled for a little (or long?) while until a human reactivates it. The benefit is we are creating a workflow in which checking throttled filters (and potentially figuring out a better way to implement them to avoid throttling) is much more likely to happen; after all, a user has to visit the filter to reactivate it.

If a properly created filter is being tripped too often, that would be indication to increase the consequences from preventing the action -> automatic short block.

If a filter is being tripped way too often, I would not call it "properly created". A properly created filter is one that utilizes the capabilities of the system (system = AbuseFilter + MediaWiki + WMF servers) reasonably and is appropriate for its context (context = how often the wiki is edited, how likely it is that a single user could overwhelm filters by repeated attempts, etc.). A filter is tripped too often, clearly it is missing the point about system and context.

If everyone who has access to Abusefilter were more proactive in watching filter changes, having the option to reactivate or throttle exempt should be a minor concern. If the team trusts each other and holds each other accountable, this is a non issue. This sounds like a lack of confidence where in WMF's case, the technical skills exist but few are willing to act as check & balance.

Correct. We are not employees; we are volunteers. Whatever feels like scut work (such as repeatedly monitoring filters) will likely not be done systematically by volunteers. Hoping that it will be, and designing a volatile system as a result, is just a set up for failure.

In T183099#7762104, @Huji wrote:

No confusion here, @Daimona. The point I am making is: if a filter is both making tons of hits AND exempted from throttle, it could be a big deal. Throttling can at least turn it off after a certain number of hits, thereby saving the servers from the stress, and the users from delayed page loads/saves.

The filter wouldn't be turned off, just its dangerous actions be disabled, but the filter would still be checked for each edit.

In T183099#7762729, @SpookyGhost8 wrote:

@Daimona "implement a button for reactivating a filter" means that upon clicking the button, the filter would be enabled immediately or upon job queue finishing the job. having to wait 24 hours defeats the purpose of the button, especially for a critical filter.

The filter would be unthrottled immediately. The thing with the 24h is that after you unthrottle a filter, it may get throttled again until the 24 hours have passed.

At that point, may as well just make a pointless null edit. A null edit works but not everyone has time to do so to avoid massive disruption or clean up later.

It's not the same thing. Aside from the obvious differences between a "null" edit and a button (mainly, that the latter is more convenient), the button would not reset the time-since-last-edit timer, whereas a normal edit would.

In T183099#7765456, @Daimona wrote:

In T183099#7762104, @Huji wrote:

No confusion here, @Daimona. The point I am making is: if a filter is both making tons of hits AND exempted from throttle, it could be a big deal. Throttling can at least turn it off after a certain number of hits, thereby saving the servers from the stress, and the users from delayed page loads/saves.

The filter wouldn't be turned off, just its dangerous actions be disabled, but the filter would still be checked for each edit.

Oh, really. What is the point of running the filter if it cannot take any actions?

You can check the log to understand its behavior.

@Daimona Why is there a need for 24 grace period? I am unsure what suitable solution exists 

@Huji There is a difference between regular users tripping the filter vs malicious bots taking actions. I have already noted my use case is to deal with malicious bots that will not leave and will just flood user accounts then spam links. Perhaps I should just give up with this and just pay for cleantalk's antispam service that apparently has the ability to trap bots with invisible checkboxes only bots can see. Perhaps a profanity filter is not as high priority but having to use revisiondelete really isn't ideal.

In T183099#7765704, @Huji wrote:

Oh, really. What is the point of running the filter if it cannot take any actions?

It can, only the dangerous actions are disabled.

In T183099#7766023, @SpookyGhost8 wrote:

@Daimona Why is there a need for 24 grace period? I am unsure what suitable solution exists 

I'm not sure I understand the question.

@Daimona Is there a particular trade off analysis for the possible chance of the filter getting throttled within the 24 hours it takes for the filter age to reset? Why can't the filter age just be reset as soon as the job in the job queue is completed?

In any case, it seems abusefilter is the wrong solution to my use case unless I can keep a filter always running with its dangerous actions regardless of the hit counter. Clearly there needs to better built-in countermeasures for mass unnatural account registrations aka by bot activity.