Skip to content

Media: Clarify batch resize failure handling and remove dead per-thumbnail fallback #77247

@adamsilverstein

Description

@adamsilverstein

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.

Metadata

Metadata

Labels

[Feature] Client Side MediaMedia processing in the browser with WASM[Status] In ProgressTracking issues with work in progress[Type] BugAn existing feature does not function as intended

Type

No fields configured for Bug.

Projects

Status

📋 Iteration/Tracking Issues

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions