This blew up in the logs as soon as I rolled group0 to wmf.4:
Notice: Undefined variable: wgAbuseFilterAvailableActions in /srv/mediawiki/wmf-config/abusefilter.php on line 23
This blew up in the logs as soon as I rolled group0 to wmf.4:
Notice: Undefined variable: wgAbuseFilterAvailableActions in /srv/mediawiki/wmf-config/abusefilter.php on line 23
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
Workaround for T136644 | operations/mediawiki-config | master | +13 -0 |
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | thcipriani | T136040 MW-1.28.0-wmf.4 deployment blockers | |||
Resolved | PRODUCTION ERROR | Tgr | T136644 Notice: Undefined variable: wgAbuseFilterAvailableActions in /srv/mediawiki/wmf-config/abusefilter.php on line 23 |
Mentioned in SAL [2016-05-31T20:55:24Z] <thcipriani> rolling back group0 wmf.4 for T136644 too much log spam
"AbuseFilterAvailableActions" should be converted to an associative array, so in config the things that need to be disabled can be set to => false instead of requiring array_diff and whatnot, and any calling code that needs to read from $wgAbuseFilterAvailableActions can use array_keys( array_filter( ... ) ); first.
Change 292036 had a related patch set uploaded (by Gergő Tisza):
Workaround for T136644
Mentioned in SAL [2016-05-31T21:43:51Z] <thcipriani@tin> Synchronized wmf-config/abusefilter.php: [[gerrit:292036|Workaround for T136644]] (duration: 00m 30s)
Your workaround really does not work. The default options from extension.json are now getting appended after the options in our config, which means that a) it is actually impossible to disable any of them, and b) it's resulting in AF attempting to insert duplicate rows into its tables, which fails (T136929). This makes it impossible to edit filters (and possibly loses data when a filter is edited, I'm not exactly sure). I think we should revert 8c937957c0f472d6be952a64da511348ae877889 and e71808f4c4deca416ecd39160d12f2584bfb9d65 in AbuseFilter today and deploy that.
[snip]
I think we should revert 8c937957c0f472d6be952a64da511348ae877889 and e71808f4c4deca416ecd39160d12f2584bfb9d65 in AbuseFilter today and deploy that.
+1, sensible choice on a Friday. @thcipriani can you do that?
Change 292572 had a related patch set uploaded (by Gergő Tisza):
Revert "Workaround for T136644"