Description
Details
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | matmarex | T132048 Change $wgAbuseFilterConditionLimit for wikimedia commons | |||
| Resolved | matmarex | T132200 Enable $wgAbuseFilterProfile on Commons for a few days | |||
| Resolved | matmarex | T132189 Restore display of number of conditions used by filter on the filter's page, gated by new config variable $wgAbuseFilterProfile |
Event Timeline
Change 282806 had a related patch set uploaded (by Bartosz Dziewoński):
Enable $wgAbuseFilterProfile for commonswiki
Change 283243 had a related patch set uploaded (by Bartosz Dziewoński):
Disable $wgAbuseFilterProfile for commonswiki
I scheduled the "Enable" patch for deployment today evening (after the 1.27.0-wmf.21 train deployment which will bring this feature to Commons). I hope we'll be able to deploy the "Disable" patch in a week or so.
Mentioned in SAL [2016-04-14T00:23:36Z] <dereckson@tin> Synchronized wmf-config/abusefilter.php: Enable $wgAbuseFilterProfile for commonswiki ([[Gerrit:282806]], Task T132200) (duration: 00m 28s)
Okay, the data is being recorded now. It might be underreporting the numbers for a while (filters for around 500 actions were executed between the deployment of https://gerrit.wikimedia.org/r/#/c/283247/ and https://gerrit.wikimedia.org/r/#/c/282806/, they'll be counted as if they took 0 ms and 0 conditions), but this should be a drop in the bucket in a few hours. (We should probably have a maintenance script to clear these stats.)
Change 283243 abandoned by Bartosz Dziewoński:
Disable $wgAbuseFilterProfile for commonswiki
Reason:
Enabling this doesn't seem to have caused a noticeable performance hit, so I think we can leave it on.
Change 283243 restored by Chad:
Disable $wgAbuseFilterProfile for commonswiki
Reason:
This has resulted in a fairly massive spike in duplicate key fetched errors in logstash. Going to disable again.