Short answer: issue a generated-video download URL only after the persisted asset is ready and its moderation evidence covers the bytes a buyer will receive. OCR coverage belongs in that release gate, not in a browser guess about whether a worker has finished.
The page that wakes me is rarely the first failure. A seller sees a clip in the download center, clicks it, and gets a file that cannot yet be reviewed. The queue dashboard stays green because work is moving. I've been paged for missed jobs and duplicate deliveries; both incidents began with a client treating “accepted by the worker” as “safe to publish.”
That is the gate.
In a marketplace, the source is often a seller photo. OCR extracts a phone number, brand claim, or prohibited phrase, while a video service turns approved images into a listing clip. The link is therefore a release capability. It must wait for durable media bytes and the moderation record that explains why those bytes may leave the internal workflow.
The failure sequence is easy to reproduce in a test harness. A worker writes the encoded object, reports success, and then loses its lease before the asset row records the moderation decision. The download center sees a successful job and asks for a link; a second worker receives the lease, repeats the write, and emits a different derivative revision. If the URL service trusts the job event, the first browser can receive bytes that have no OCR record, while a retry can point at the second revision. The fix is to make publication a transaction over identity and evidence: the object revision, codec metadata, OCR result, policy version, and allowed decision become visible together. A status event can wake a poller, but it cannot authorize delivery by itself. That distinction is what keeps duplicate deliveries observable instead of silently normal.
What should generated video delivery verify before a status-gated download URL?
Persist an asset identifier before enqueueing work. Keep separate states for submitted, processing, ready, blocked, failed, and expired; collapsing them into a boolean makes moderation and operations impossible to reason about. A URL can be minted only from a ready record whose OCR decision is attached to the same asset revision.
The browser may poll for status, but the URL issuer is authoritative. It should re-read the record, check the viewer's marketplace scope, and create a short-lived capability tied to the asset ID. Never return a URL copied from an earlier poll response. The encoder may have closed its file while the metadata transaction is still pending.
Here is the boundary I keep deliberately small. A blocked listing is a normal outcome, not an exception that gets retried forever.
package delivery
import (
"context"
"errors"
)
type State string
const (
Ready State = "ready"
Blocked State = "blocked"
)
type Asset struct {
ID string
State State
OCRComplete bool
Allowed bool
}
type Store interface {
GetAsset(ctx context.Context, id string) (Asset, error)
MintDownloadURL(ctx context.Context, id string) (string, error)
}
func DownloadURL(ctx context.Context, store Store, id string) (string, error) {
asset, err := store.GetAsset(ctx, id)
if err != nil {
return "", err
}
if asset.State != Ready || !asset.OCRComplete || !asset.Allowed {
return "", errors.New("asset is not releasable")
}
return store.MintDownloadURL(ctx, asset.ID)
}
The check is repeatable. A refresh, a second browser tab, and a queue redelivery can all call it without creating another video. Generation needs an idempotency key; delivery needs a stable read. Those are different contracts.
How do OCR coverage and generated video status shape the moderation workflow?
Moderation coverage is a policy decision, not a model-shaped promise. Define what OCR must see before release: all frames, a sampled set, or only the seller's source images. Sampling may be reasonable for a fast internal preview, but it is a poor fit when text can appear briefly in a generated transition. Record the policy version with the asset so a later reviewer can tell why a link was allowed.
I use a small decision table during design reviews:
| Constraint | Release after source OCR | Release after clip OCR |
|---|---|---|
| Text is preserved from seller photos | Lower latency; simpler lineage | Extra processing step |
| Text can appear during transitions | Coverage gap | Better evidence for delivered bytes |
| Reviewers need frame-level proof | Add source-to-frame mapping | Store timestamps with OCR results |
| Policy changes often | Re-evaluate source records | Re-evaluate the exact derivative |
The catch is that source-only OCR is not suitable when rendering can introduce captions, overlays, or watermarks. Stick with clip-level evidence when the moderation rule applies to what buyers actually download. Your mileage may vary: the right threshold depends on how much text your generation template can add and how costly a false negative is.
What does the download center show at each state?
The download center should expose a state transition, not a spinner with a hidden promise. submitted means the request was accepted and has an ID. processing means work is still in flight. ready means both the derivative and its moderation decision are durable. blocked needs a review path; failed needs an explicit retry policy; expired needs retention messaging.
At ready, fetch a fresh URL. At every other state, keep the download action absent or clearly unavailable. Stop polling at terminal states. An interval that continues after a rejection creates noise and can mask a real queue-age alert.
The media format is part of this contract. A browser may play one container while a moderation tool expects another, and a generated file can be valid but still unusable to the intended reviewer. Record the container and codec, validate them before publication, and document fallback behavior using the MDN media-format guidance. Do not infer format from a filename supplied by a seller.
Which signals catch a stuck release before a buyer does?
Start from the page and work backward. Alert on the age of the oldest non-terminal asset, the rate of ready transitions, and the ratio of URL requests rejected because an asset is not ready. A rising rejection ratio is useful only when paired with queue depth; a traffic spike can otherwise look like an outage.
Log the asset ID, source ID, derivative revision, state transition, policy version, and idempotency key. Avoid logging the signed URL itself. Trace the transition that should have produced the ready asset, then compare object metadata with the database record. In one recurring postmortem pattern, the encoder finished but the metadata write lagged; the repair is an atomic publication transition, not faster client polling.
Thresholds have a cost. Page too early and an ordinary long clip trains the team to ignore alerts. Page too late and the download center becomes a support queue. I'm not sure a single percentile works for every resolution, so I keep a product-level maximum age and review it against real clip durations.
When is status-gated delivery the wrong fit?
Status-gated URLs fit generated clips with a clear terminal asset and a download-center experience. They are not suitable for live streams, collaborative editing, or a requirement for permanent public URLs. Those cases need a streaming session, a versioned manifest, or a durable object policy with different ownership of bytes and permissions.
Signed URLs also do not replace authorization. Check access when minting the URL, bind the request to the asset and marketplace tenant, and give the capability a short lifetime. Record the issuance event for audit, then let storage enforce expiration.
The false-positive cost deserves a line in the runbook: an over-eager release can expose prohibited text, while an over-strict gate can strand legitimate inventory. Measure both. The correct alert is the one that leads to a reviewable decision, not merely a red dashboard tile.
References
- MDN Media Formats Guide: https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats
Top comments (0)