Showed up in drift report using abstract schema:
"filearchive fa_deleted_timestamp field-type-mismatch": { "s1": [ "db1083:enwiki", "db1084:enwiki", "db1169:enwiki", "db1118:enwiki", "db1163:enwiki", "db1106:enwiki", "db1164:enwiki", "db1119:enwiki", "db1134:enwiki" ], "s2": [ "db1122:svwiki", "db1129:svwiki", "db1076:svwiki", "db1074:svwiki" ], "s3": [ "db1123:aswikibooks", "db1166:aswikibooks", "db1157:aswikibooks", "db1175:aswikibooks", "db1112:aswikibooks" ], "s6": [ "db1131:ruwiki", "db1168:ruwiki", "db1085:ruwiki", "db1173:ruwiki" ], "s7": [ "db1086:cawiki", "db1127:cawiki", "db1136:cawiki", "db1079:cawiki" ] },
At first, I thought it was a mistake in abstraction (T42626: Standardise type of timestamp database fields (MySQL) T230428: Migrate tables.sql to abstract schema) but in the old code it was binary(14) and hasn't changed since 2007.
In production it's
wikiadmin@10.64.32.77(enwiki)> desc filearchive; +----------------------+-------------------------------------------------------------------------------------------------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +----------------------+-------------------------------------------------------------------------------------------------------------+------+-----+---------+----------------+ | fa_deleted_timestamp | varbinary(14) | YES | MUL | | |
While in the code it's fa_deleted_timestamp BINARY(14) DEFAULT NULL, (and it should be this). The same situation applies to fa_timestamp field as well
ALTER TABLE /*_*/filearchive MODIFY fa_deleted_timestamp BINARY(14) DEFAULT NULL, MODIFY fa_timestamp BINARY(14) DEFAULT NULL;
Schema change progress:
- s1
- eqiad
- codfw
- s2
- eqiad
- codfw
- s3
- eqiad
- codfw
- s4
- eqiad
- codfw
- s5
- eqiad
- codfw
- s6
- eqiad
- codfw
- s7
- eqiad
- codfw
- s10
- labtestwiki
Confirmed that s8 is not affected.