Jul 21 11:03:58 mw1181: #012Catchable fatal error: Argument 4 passed to WikibaseQuality\ConstraintReport\Constraint::__construct() must be an instance of array, null given in /srv/mediawiki/php-1.30.0-wmf.10/extensions/Wikidata/extensions/Constraints/includes/ConstraintRepository.php on line 145
Happening when accessing https://www.wikidata.org/wiki/Special:ConstraintReport/Q42.
Do you have any other information? Stack trace, anything?
Can you perhaps send me contents of the wbqc_constraints table? (It’s not yet available on Quarry, so I can’t look at the constraint parameters to see if anything’s wrong.)
Change 366834 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Default constraint parameters to []
I uploaded a quick’n’dirty fix, but I have no idea why it’s necessary, and I’d like to understand that. Are there any constraints in the table with constraint parameters "null", or with invalid JSON, or with an empty column?
Okay, the new version of the fix also includes logging, so that should hopefully give us more information too (if you agree that the logging is a good idea and backport the fix with it included).
No, sadly I have just the above error.
Can you perhaps send me contents of the wbqc_constraints table? (It’s not yet available on Quarry, so I can’t look at the constraint parameters to see if anything’s wrong.
I couldn't find anything suspicious in the data myself (but I didn't look in detail), so I just dumped the table for now: https://people.wikimedia.org/~hoo/tmp/wbqc_constraints-2017-07-21.xz
Hm, line 4367 (grep for 0f3eaaa5603250aa8f95ef50396ac73dfef58339) seems to be truncated. Did that happen during the table dump or is it truncated in the database?
If it’s truncated in the database, then it looks like the overlong exception list for “taxon name” (and a few others) is causing the trouble.
And it looks like some regex (grep for 2f15c2589f391670c05a92158acb29bb98969d7e) might be incorrectly escaped.
{"P1793":{"0":{"snaktype":"value","property":"P1793","hash":"2f15c2589f391670c05a92158acb29bb98969d7e","datavalue":{"value":"[\\\\w+]+:\\\\\\/\\\\\\/[^\\"<>\\\\s]+\\\\$1[^\\"<>\\\\s]*","type":"string"}}}}
EDIT: Nevermind, I think the dump just added an extra layer of escaping. Once I undo that, the problem vanishes, and locally I observed correctly escaped patterns in phpmyadmin.
That value is truncated in the database as well (length is 65535), because the field is a blob… I guess it should be a mediumblob instead.
For now I guess discarding (and logging) invalid values would be ok. But mid-term the field should be altered or overly long values need to be forbidden (which might also be a good idea considering performance?).
For now I guess discarding (and logging) invalid values would be ok. But mid-term the field should be altered or overly long values need to be forbidden (which might also be a good idea considering performance?).
Yeah, the attached change should be enough for now, and for the next deployment I’ll try to modify the updater so that it discards overly long constraint parameters and they’re properly reported as errors.
Change 366834 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Default constraint parameters to []
Change 366860 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Add missing import
Change 366860 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Add missing import
That value is truncated in the database as well (length is 65535), because the field is a blob… I guess it should be a mediumblob instead.
I don’t understand… the database silently truncated the value without error? I just tried to add a test for this, but when I insert a long value locally, I get a \Wikimedia\Rdbms\DBQueryError and nothing ends up in the database.
@daniel wow, thanks… I’ll try to account for both possibilities so the test works locally and in prod. (I assume the CI systems also don’t have strict mode.)
Change 366883 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Detect overlong constraint parameters on DB insert
Change 366884 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Report unimportable constraint parameters
Okay, the two new commits properly fix this issue, I think. But I’d appreciate it if someone could backport the first two commits (I2002e3aa72 and I90c7dbce76) before the next deployment.
By the way, the affected properties are: taxon name (P225), category's main topic (P301), Commons category (P373), INSEE municipality code (P374), IMA status and/or rank (P579), GNIS ID (P590). Any item with a statement for one or more of these properties gets the error.
Change 366895 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@wmf/1.30.0-wmf.10] Default constraint parameters to []
Change 366895 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@wmf/1.30.0-wmf.10] Default constraint parameters to []
Thanks! But the patches with the proper fix for this are still open for review. Or should I create a different task for those?
Change 366883 abandoned by Lucas Werkmeister (WMDE):
Detect overlong constraint parameters on DB insert
Reason:
Abandoning in favor of I52e842e50b, which is much simpler.