[{reqId}] {exception_url} TypeError: Argument 1 passed to MediaWiki\Extension\AbuseFilter\Variables\VariableHolder::newFromArray() must be of the type array, null given, called in /srv/mediawiki/php-1.44.0-wmf.19/extensions/AbuseFilter/includes/Variablewikiadmin2023@10.192.0.31(enwiki)> select afl_var_dump,afl_timestamp from abuse_filter_log where afl_id=11355083; +--------------+----------------+ | afl_var_dump | afl_timestamp | +--------------+----------------+ | tt:645962183 | 20150102213332 | +--------------+----------------+ 1 row in set (0.000 sec) wikiadmin2023@10.192.0.31(enwiki)> select * from text where old_id=645962183; +-----------+-------------------------+---------------------+ | old_id | old_text | old_flags | +-----------+-------------------------+---------------------+ | 645962183 | DB://cluster27/28413100 | utf-8,gzip,external | +-----------+-------------------------+---------------------+ 1 row in set (0.001 sec)
daimona@mwmaint2002:~$ mwscript fetchText.php --wiki enwiki DEPRECATION WARNING: Maintenance scripts are moving to Kubernetes. See https://wikitech.wikimedia.org/wiki/Maintenance_scripts for the new process. Maintenance hosts will be going away; please submit feedback promptly if maintenance scripts on Kubernetes don't work for you. (T341553) tt:645962183 tt:645962183 0
Uhmmmm I'm not sure what to make of it. I thought we'd fixed all instances of bad blobs in T246539. I'm not sure how 0 might have ended up here either.
FWIW, I've also checked the blobs for the abuselog entries immediately before (20150102213325) and immediately after (20150102213424) the affected one. They both look correct.
Random attempt: do we have backups from 2015-2020 that we could use to check if this has always been the value for that row? I'm not sure how likely it might be, but I'd like to make sure that I didn't break this value in 2020 when fixing bad blobs.
Note that the data fetchText is displaying the the empty string, not the string 0. Per https://www.mediawiki.org/wiki/Manual:FetchText.php it first prints the length of the string, not the string itself.
(And thanks for reminding me that maintenance script existed - it would be useful for an unrelated DB corruption task I have been working on)
Ah, I see, thank you. An empty value definitely makes much more sense than "0". Still, I'm wondering how it might have happened. At the time we should've been running 1.25-wmf.13. The branch has been pruned and I'm too lazy to go find the actual code, but checking REL1_25, I don't see how the value became empty. Back then we used PHP serialization to store blobs, but serialize cannot return the empty string, not even when the input itself is empty-ish. So, my only two guesses are 1) low-level failure in external storage, or 2) after-the-fact value manipulation, for example a bug in the UpdateVarDumps script mentioned above.