I suspect that MediaWiki Interfaces was tagged because the entry point is api.php, but the actual issue seems to be in /Media/GIFHandler.

Please retag us if I'm mis-triaging.

In T422847#11805754, @BPirkle wrote:

I suspect that MediaWiki Interfaces was tagged because the entry point is api.php, but the actual issue seems to be in /Media/GIFHandler.

Please retag us if I'm mis-triaging.

Thank you @BPirkle. I was flailing.

Change #1269598 had a related patch set uploaded (by Umherirrender; author: Umherirrender):

[mediawiki/core@master] Media: Check to return array from GIFHandler::getCommonMetaArray

https://gerrit.wikimedia.org/r/1269598

Change #1269598 merged by jenkins-bot:

[mediawiki/core@master] Media: Check to return array from GIFHandler::getCommonMetaArray

https://gerrit.wikimedia.org/r/1269598

"The 'metadata' key could be an string,"

I was curious why this would suddenly happen. It seems that this is triggered by file Mannlicher-Schoenauer_1903_drawing.gif on Commons which seems to be a pretty old file, so why do we suddenly have this error ?

I've looked at the db data and it's img_metadata field looks like:

a:3:{s:10:"frameCount";i:1;s:6:"looped";b:0;s:8:"duration";d:0;}

A normal frame (that is also still php serialized, as modern serialization is in json) looks like:

a:4:{s:10:"frameCount";i:1;s:6:"looped";b:0;s:8:"duration";d:0;s:8:"metadata";a:1:{s:15:"_MW_GIF_VERSION";i:1;}}

I suspect this is a bug in loadMetadataFromString, which isn't able to handle very old GIF metadata entries.

A wait, it's fetching the metadata for an old version.. (OldLocalFile)

I found this on commons:

a:4:{s:5:"width";i:1000;s:6:"height";i:285;s:8:"metadata";s:358:" <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:cc="http://creativecommons.org/ns#" xmlns:dc="http://purl.org/dc/elements/1.1/"> <cc:Work rdf:about=""> <dc:format>image/svg+xml</dc:format> <dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage"/> <dc:title/> </cc:Work> </rdf:RDF> ";s:7:"version";i:2;}

One of the revisions of the image is an SVG instead of a GIF, and the metadata for that revision does indeed have a string metadata subelement.
There are 498879 old revisions and 637897 current revisions of SVG in this format, so that structure is common for SVGs

Strange that it used the GIFHandler for an old file record that is marked in the DB as being of type SVG for that version. That means it initialized the handler based on the current revisions' mime type, instead of the old file's mime type. Don't remember if that is expected...

Actually doing the same request on Commons against the api DOES work.

https://commons.wikimedia.org/wiki/Special:ApiSandbox#action=query&format=json&prop=imageinfo&titles=File%3AMannlicher-Schoenauer_1903_drawing.gif%7CFile%3AM1903xf.jpg%20&formatversion=2&iiprop=archivename%7Cbadfile%7Cbitdepth%7Ccanonicaltitle%7Ccomment%7Ccommonmetadata%7Cdimensions%7Cextmetadata%7Cmediatype%7Cmetadata%7Cmime%7Cparsedcomment%7Csha1%7Csize%7Cthumbmime%7Ctimestamp%7Cuploadwarning%7Curl%7Cuser%7Cuserid&iilimit=max

Fails:

https://el.wikipedia.org/wiki/Special:ApiSandbox#action=query&format=json&prop=imageinfo&titles=File%3AMannlicher-Schoenauer_1903_drawing.gif%7CFile%3AM1903xf.jpg%20&formatversion=2&iiprop=archivename%7Cbadfile%7Cbitdepth%7Ccanonicaltitle%7Ccomment%7Ccommonmetadata%7Cdimensions%7Cextmetadata%7Cmediatype%7Cmetadata%7Cmime%7Cparsedcomment%7Csha1%7Csize%7Cthumbmime%7Ctimestamp%7Cuploadwarning%7Curl%7Cuser%7Cuserid&iilimit=max

so it might be a ForeignDbRepo problem ????

Maybe this is due to changes related to T28741 ? In the new file/filerevision situation, we only allow a single filetype for all of the revisions of one file entry... and el.wikipedia might be switched over already to read from the new tables T416548 and then ForeignDbRepo would read using the new tables as well, detect gif type, and initialize the GIFHandler for the file revision, which is then unable to read out the SVG specific metadata of that revision ?