Media processing: failure is a first-class state #168
Labels
No labels
kind
bug
kind
enhancement
wayfinder
grilling
wayfinder
map
wayfinder
prototype
wayfinder
research
wayfinder
task
workflow
needs-info
workflow
needs-triage
workflow
ready-for-agent
workflow
ready-for-human
workflow
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
rosa/vernier#168
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Part of the "defer media processing to a background job" spec (PR #165; ADR-0020).
Completes the deferred pipeline by making failure a first-class outcome rather than
an endlessly-retried job.
What to build
Have the
optimize_mediajob classify its failures and drive the Media to aterminal Failed state where appropriate.
A permanent failure — bytes that passed the request-path magic-byte sniff but
are undecodable, a decompression bomb over the decode bound, anything outside the
allowlist — marks the Media Failed, deletes the staged original, and does not
retry (maps to the terminal
Error::Abortclassification). A transient failure— out of memory under load, a full disk — retries with backoff a bounded number of
times (maps to the retryable
Error::Failed), and once retries are exhausted theMedia falls to Failed.
Because the upload was fire-and-forget, a Failed Media is surfaced on its author's
own views rather than left to render as a silently broken image. (A dedicated
notification channel beyond surfacing the status is out of scope — spec.)
Acceptance criteria
GET /media/{id}returns 404 for a Failed Media, and its Photo stays omitted from page and feeds.Blocked by