[3:48pm] no_justification: awight: Spotted in production: [{exception_id}] {exception_url} MWException from line 140 of /srv/mediawiki/php-1.31.0-wmf.11/includes/Preferences.php: Global default 'soft' is invalid for field rcOresDamagingPref
The default value "soft" is the older style of threshold preference, I don't understand why it would be invalid.
@Ladsgroup is saying that people can't check or change their preferences on fawiki because of this.
2017-12-09 10:52:14 [WivAXgpAEKsAABFZlbQAAABQ] mw1216 fawiki 1.31.0-wmf.11 exception ERROR: [WivAXgpAEKsAABFZlbQAAABQ] /wiki/%D9%88%DB%8C%DA%98%D9%87:%D8%AA%D8%B1%D8%AC%DB%8C%D8%AD%D8%A7%D8%AA MWException from line 140 of /srv/mediawiki/php-1.31.0-wmf.11/includes/Preferences.php: Global default 'soft' is invalid for field rcOresDamagingPref {"exception_id":"WivAXgpAEKsAABFZlbQAAABQ","exception_url":"/wiki/%D9%88%DB%8C%DA%98%D9%87:%D8%AA%D8%B1%D8%AC%DB%8C%D8%AD%D8%A7%D8%AA","caught_by":"mwe_handler"}
[Exception MWException] (/srv/mediawiki/php-1.31.0-wmf.11/includes/Preferences.php:140) Global default 'soft' is invalid for field rcOresDamagingPref
#0 /srv/mediawiki/php-1.31.0-wmf.11/includes/Preferences.php(93): Preferences::loadPreferenceValues(User, RequestContext, array)
#1 /srv/mediawiki/php-1.31.0-wmf.11/includes/Preferences.php(1353): Preferences::getPreferences(User, RequestContext)
#2 /srv/mediawiki/php-1.31.0-wmf.11/includes/specials/SpecialPreferences.php(127): Preferences::getFormObject(User, RequestContext)
#3 /srv/mediawiki/php-1.31.0-wmf.11/includes/specials/SpecialPreferences.php(84): SpecialPreferences->getFormObject(User, RequestContext)
#4 /srv/mediawiki/php-1.31.0-wmf.11/includes/specialpage/SpecialPage.php(522): SpecialPreferences->execute(NULL)
#5 /srv/mediawiki/php-1.31.0-wmf.11/includes/specialpage/SpecialPageFactory.php(578): SpecialPage->run(NULL)
#6 /srv/mediawiki/php-1.31.0-wmf.11/includes/MediaWiki.php(287): SpecialPageFactory::executePath(Title, RequestContext)
#7 /srv/mediawiki/php-1.31.0-wmf.11/includes/MediaWiki.php(851): MediaWiki->performRequest()
#8 /srv/mediawiki/php-1.31.0-wmf.11/includes/MediaWiki.php(523): MediaWiki->main()
#9 /srv/mediawiki/php-1.31.0-wmf.11/index.php(43): MediaWiki->run()
#10 /srv/mediawiki/w/index.php(3): include(string)
#11 {main}Change 396572 had a related patch set uploaded (by Ladsgroup; owner: Amir Sarabadani):
[operations/mediawiki-config@master] Disable ORES in fawiki
Change 396572 merged by jenkins-bot:
[operations/mediawiki-config@master] Disable ORES in fawiki
Mentioned in SAL (#wikimedia-operations) [2017-12-09T11:19:27Z] <legoktm@tin> Synchronized wmf-config/InitialiseSettings.php: Disable ORES in fawiki - T182354 (duration: 00m 45s)
Disabled ORES on fawiki for now. This only affected fawiki because of the following:
$wgDefaultUserOptions['rcOresDamagingPref'] = 'soft'; $wgOresFiltersThresholds['damaging']['likelybad'] = false;
fawiki is the only one with likelybad set to false. 'soft' maps to 'likelybad' in Hooks::$damagingPrefMap, but since it's set to false, "soft" is not added as one of the options. The fact that the default is not a valid option throws an exception.
Do you check changes you implement in different configs and systems? Aren't there any integration tests? or tests at all?
@Arash.pt Taking your questions at face value: Yes, yes and yes :). The issue here is that it's difficult to write tests that cover scenarios we haven't seen before, such as exotic combinations of settings. Now that we know about this problem, we can write a regression test for it (https://en.wikipedia.org/wiki/Regression_testing) which will prevent it from happening again.
If you're inspired to contribute, just look in the tests directory for any of our repositories. In this case, https://github.com/wikimedia/mediawiki-extensions-ORES/tree/master/tests/phpunit/includes
Change 396805 had a related patch set uploaded (by Catrope; owner: Catrope):
[operations/mediawiki-config@master] Give rcOresDamagingPref the same default as oresDamagingPref
Change 396806 had a related patch set uploaded (by Catrope; owner: Catrope):
[operations/mediawiki-config@master] Revert "Disable ORES in fawiki"
Change 396805 merged by jenkins-bot:
[operations/mediawiki-config@master] Give rcOresDamagingPref the same default as oresDamagingPref
Change 396806 merged by jenkins-bot:
[operations/mediawiki-config@master] Revert "Disable ORES in fawiki"
Mentioned in SAL (#wikimedia-operations) [2017-12-12T00:39:37Z] <catrope@tin> Synchronized wmf-config/InitialiseSettings.php: Re-enable ORES on fawiki (T182354) (duration: 00m 56s)
Asking because User-notice has been added – is this problem isolated to fa.wikipedia.org or has it been more wide-spread than so?
@Johan This only affected fawiki, to my knowledge. Feel free to change tags as necessary, thanks!
It was only in fawiki but user-facing, if you think it's not needed feel free to remove it.
Thanks. The reason I'm asking is that Tech News is a very ineffective way to reach out to individual wikis – it's a great tool when it affects everyone, but you've already done more by posting on the Village Pump than Tech News can do for fawiki.
(We generally avoid posting about individual wikis for this reason – it's easier to just go to that specific wiki and explain the situation. The exceptions are Commons and Wikidata, because other wikis depend on them.)
This is a very old task which is implicitly resolved but not explicitly. Let's please move any Wikimedia-Incident (active situation) tasks in any team backlog to "doing" (or similar) so that they don't get lost in the future. Incidents should trump all other work until resolved/closed.