If a single asset in the array passed to insertOrUpdateAssets cannot be read, the returned
AsyncSequence throws and delivers zero elements — including for the valid assets that appear
before the offending one in the array.
In my measurement a batch of 5 — two valid photographs, one zero-byte .jpg, then two more valid
photographs — delivered 0 of 5 elements and reported 0 faces. The framework's own stdout log shows
it had already processed the valid photographs before failing, so the work was done and then
thrown away.
This is the behaviour I would expect from a function returning [Result] after processing
everything, not from a streaming AsyncSequence. The whole reason to expose an async sequence is
to deliver results as they are produced; here the sequence produces nothing at all, which makes
the streaming shape actively misleading.
Why this matters at library scale. I am cataloguing 97 photo libraries, many of them archives of scanned family photographs going back to the 1970s, where a handful of damaged files is normal rather than exceptional. As the API stands, the batch size I choose for throughput is also the amount of work a single corrupt file destroys — with a batch of 100, one bad file costs 100 images. The only safe strategy is to catch the failure and re-submit the batch one asset at a time to find the culprit, which turns a rare bad file into a full re-run of that batch and makes the worst case quadratic in the number of bad files.
Note also that the error gives no indication of which asset failed (see the related enhancement request on error taxonomy), so isolating the culprit by re-submission is the only option available.
Feedback: FB24174733