Background
In #76979, packages/upload-media/src/store/private-actions.ts added a batch path via batchResizeImage() with a fallback else branch that queues per-thumbnail resize operations if the batch path isn't taken.
During review, @andrewserong asked when we'd expect the batch path to fail but the per-thumbnail path to succeed:
I'm curious if there's a case where batch will fail but per-thumbnail will succeed. My assumption (e.g. if there's a corrupt image) is that we'd bail entirely rather than trying another approach to processing/uploading. […] Mostly my thinking was if this `else` condition isn't required then we could remove some code 😄
If the two code paths fail under the same conditions (corrupted source, unsupported format, OOM in WASM, etc.), the else branch is dead code and should be deleted. If there are failure modes unique to batch mode that per-thumbnail can recover from, that needs to be documented and covered by tests.
Acceptance criteria
- Enumerate the failure modes of
batchResizeImage() vs the per-thumbnail path.
- If no divergence exists, remove the per-thumbnail fallback branch and simplify the action.
- If divergence exists, add tests that cover the fallback transition and document why the fallback is retained.
- Coordinate with the broader error-handling work for client-side media processing.
Background
In #76979,
packages/upload-media/src/store/private-actions.tsadded a batch path viabatchResizeImage()with a fallbackelsebranch that queues per-thumbnail resize operations if the batch path isn't taken.During review, @andrewserong asked when we'd expect the batch path to fail but the per-thumbnail path to succeed:
If the two code paths fail under the same conditions (corrupted source, unsupported format, OOM in WASM, etc.), the
elsebranch is dead code and should be deleted. If there are failure modes unique to batch mode that per-thumbnail can recover from, that needs to be documented and covered by tests.Acceptance criteria
batchResizeImage()vs the per-thumbnail path.