An image file whose data is cut in half is accepted by insertOrUpdateAssets, produces no error,
and is reported as an image containing zero faces. That result is indistinguishable from a
photograph that genuinely has no people in it.
In my measurement the intact file reported 4 faces and a copy truncated to half its bytes reported 0 faces — both without throwing.
Why this is worse than an error. A client that receives "zero faces, no error" will record the asset as analysed, no people present. That is a permanent, silent, incorrect result: the file is never revisited, and the people in it are lost from the catalogue with no diagnostic anywhere. An error would have been recorded as a failure and retried later. Silence is the one outcome that cannot be recovered from.
The failure mode is also inconsistent. Other kinds of damaged input do throw — a zero-byte
file, a text file with a .jpg extension, and a file whose interior bytes have been destroyed all
raise MediaIntelligenceError.faceGroupProcessing. Truncation is the case that silently succeeds,
and truncation is precisely the damage that partial downloads, interrupted copies and failing
disks produce — the most common form of corruption in a real photo archive, and the one I have to
handle in 97 libraries of mixed provenance.
My current workaround is to fully decode every image myself before handing it to the framework, purely to detect truncation. That means every file is decoded twice, which roughly doubles the I/O of the analysis pass.
Feedback: FB24174749