{
  "id": 13908441,
  "title": "A Media Asset Is a Stateful Object",
  "url": "https://urgent.news/2026/10/12/a-media-asset-is-a-stateful-object",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-12T08:19:15.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/romiteld/a-media-asset-is-a-stateful-object-1iag"
  },
  "original_language": "en",
  "account": "A media asset is a stateful object, not just a collection of bytes. The bytes may exist, but that does not guarantee the image can be shown, retried, reviewed, or published. Vehicle listings rely heavily on media, but accepting images is simple compared to ensuring the original work is preserved and the publish button remains attached. This post discusses the challenges of maintaining custody across storage, databases, vision workers, derived artifacts, human review, and publication.\n\nThe model treats a media asset as a stateful object moving through a bounded vision pipeline. Each expensive computer vision (CV) step must write back to the same asset story, or the product may display an image whose approval came from an earlier step. Intake is proven by an event, not a timestamp. The trigger is a durable row in project_events named capture.media_secured. Its idempotency key includes the capture session identifier, and the payload contains the project identifier, source asset identifiers, required and missing roles, and a processingEnqueued flag.\n\nSeparate endpoints for image work are tempting, but they break when a partial retry occurs. Derived images may exist while quality verdicts are missing, and retries can produce better frames while the listing still points to the old image. A separate status endpoint can check progress by vehicle identifier, but readiness is ultimately determined by the persistent asset graph.\n\nThe design uses Postgres to manage six check-constrained stages and states for queued, running, succeeded, failed, cancelled, and declined work. Workers claim rows with a SQL path that uses FOR UPDATE SKIP LOCKED, and stale work can be reclaimed after fifteen minutes. The service role owns the claim path, and the drainer keeps the same shape.\n\nFour lanes - storage, database, worker, and product - must agree for a listing to be ready. Storage proves the existence of signed source bytes and derived media bytes. The database records the capture media secured event and processing job rows. Workers perform matte preflight, studio render, listing generation, and marketing generation. The product displays owner visible readiness, human review queue, and publication gate. The binding between these lanes ensures the listing is only published when all conditions are met.",
  "summary": "A phone can upload a sharp photo and still leave the product with nothing usable. The bytes are there. A thumbnail may exist. A background cutout may even look clean. None of that answers the question the product actually has to answer: can this image be shown, retried, reviewed, or published? That is the failure I wanted to avoid. Vehicle listings are made out of media, yet accepting images is…",
  "key_points": [
    "Media asset is stateful object, not just bytes",
    "Vehicle listings rely heavily on media preservation",
    "Four lanes - storage, database, worker, product - must agree for listing readiness"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}