Thread a Media lifecycle status end-to-end (prefactor) #166

Closed
opened 2026-08-09 19:48:05 +00:00 by rosa · 0 comments
Owner

Part of the "defer media processing to a background job" spec (PR #165; ADR-0020,
ADR-0021, and the CONTEXT.md Processing term). This is the prefactor slice —
"make the change easy, then make the easy change" — done before any deferral so the
later change is small.

What to build

Give Media a lifecycle status of Processing / Ready / Failed, threaded through
the aggregate, the media table, and every read path — without changing any
observable behavior yet.

Media creation still optimizes inline and records the Media as Ready. Existing
rows migrate to Ready. The read paths gate on status: GET /media/{id} serves only
a Ready Media (404 otherwise), and the Post photo render and the RSS/Atom
feed-photo lookup include a Photo only when its Media is Ready — Processing and
Failed Media are omitted.

Because all media is Ready after this slice, nothing a user sees changes. The point
is that a Media that is not Ready is now correctly hidden, so the next slice can
create Processing media safely.

How the absent-until-Ready rendition data (bytes, byte_size, width, height)
is stored is an open schema decision — nullable columns, a separate rendition row
keyed by MediaId, or values read only through the status. Pick one here; ADR-0020
requires only that they are absent until Ready.

Acceptance criteria

  • The Media aggregate carries a Processing / Ready / Failed status.
  • The media schema records status; a migration sets existing rows to Ready.
  • create_media records the new Media as Ready (behavior otherwise unchanged).
  • GET /media/{id} returns 404 for a Processing or Failed Media and 200 for a Ready one.
  • The Post HTML photo element is omitted unless the Media is Ready.
  • The RSS and Atom feed-photo lookup includes a Photo only for a Ready Media.
  • Existing media upload/serve/feed tests pass unchanged; new coverage asserts a hand-inserted Processing/Failed Media 404s and is omitted from page and feeds.

Blocked by

None - can start immediately.

Part of the "defer media processing to a background job" spec (PR #165; ADR-0020, ADR-0021, and the CONTEXT.md **Processing** term). This is the prefactor slice — "make the change easy, then make the easy change" — done before any deferral so the later change is small. ## What to build Give Media a lifecycle status of **Processing / Ready / Failed**, threaded through the aggregate, the `media` table, and every read path — without changing any observable behavior yet. Media creation still optimizes inline and records the Media as **Ready**. Existing rows migrate to Ready. The read paths gate on status: `GET /media/{id}` serves only a Ready Media (404 otherwise), and the Post photo render and the RSS/Atom feed-photo lookup include a Photo only when its Media is Ready — Processing and Failed Media are omitted. Because all media is Ready after this slice, nothing a user sees changes. The point is that a Media that is *not* Ready is now correctly hidden, so the next slice can create Processing media safely. How the absent-until-Ready rendition data (`bytes`, `byte_size`, `width`, `height`) is stored is an open schema decision — nullable columns, a separate rendition row keyed by `MediaId`, or values read only through the status. Pick one here; ADR-0020 requires only that they are absent until Ready. ## Acceptance criteria - [ ] The Media aggregate carries a Processing / Ready / Failed status. - [ ] The `media` schema records status; a migration sets existing rows to Ready. - [ ] `create_media` records the new Media as Ready (behavior otherwise unchanged). - [ ] `GET /media/{id}` returns 404 for a Processing or Failed Media and 200 for a Ready one. - [ ] The Post HTML photo element is omitted unless the Media is Ready. - [ ] The RSS and Atom feed-photo lookup includes a Photo only for a Ready Media. - [ ] Existing media upload/serve/feed tests pass unchanged; new coverage asserts a hand-inserted Processing/Failed Media 404s and is omitted from page and feeds. ## Blocked by None - can start immediately.
rosa closed this issue 2026-08-10 00:09:52 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
rosa/vernier#166
No description provided.