Sume timeline warnings are not failures: a gate for your season

A completed job can still be wrong

Sume treats several problems as soft warnings and not as failures. The Timeline 1.0 page says so directly: padded or looped short sources, snapped transitions and ignored still motion come back in warnings[] on a finished render, and they do not fail the job. That is the right call for a general API, because a one-second loop on a b-roll clip is not an error to everybody. It is a problem for a season of Shorts you intend to publish unattended.

The October platform roundup puts YouTube's Shorts series, with seasons, episodes and sequential playback, in rollout from 23 September. A season is a batch, and batches need a gate between rendering and publishing, so one bad episode does not go out in the middle of a binge.

The warnings the docs name

Each of these appears in the Sume docs for the surface shown. The list is not exhaustive, which is why the gate below is an allowlist and not a blocklist.

The gate (offline, runs as written)

The script reads warnings as either plain strings or objects with a code, since the docs name codes but we do not rely on one wire shape. Anything not in EXPECTED becomes a problem, so a new warning code Sume adds later fails closed instead of slipping through. The sample data at the bottom shows one clean episode, one with an allowed warning and one that should stop.

EXPECTED = {"motion_ignored"}  # a still with motion set; harmless in this season
FAIL_FAST = {"output_fps_resamples_sources", "trim_clamped_to_source"}

def codes(result):
    return [w if isinstance(w, str) else w.get("code", "unknown")
            for w in result.get("warnings", [])]

def gate(result):
    """Return the problems that should stop an episode from publishing."""
    problems = []
    for c in codes(result):
        if c in FAIL_FAST:
            problems.append(f"{c}: fix the body, do not publish")
        elif c not in EXPECTED:
            problems.append(f"{c}: not in the expected list, look at the clip")
    return problems

results = {
    "ep01": {"video_url": "https://media.sume.com/artifacts/artf_a/ep01.mp4", "warnings": []},
    "ep02": {"video_url": "https://media.sume.com/artifacts/artf_a/ep02.mp4",
             "warnings": ["motion_ignored"]},
    "ep03": {"video_url": "https://media.sume.com/artifacts/artf_a/ep03.mp4",
             "warnings": [{"code": "output_fps_resamples_sources"}]},
}
for name, res in results.items():
    print(name, gate(res) or "ok")

Where to call it

Call gate(result) on the result object you read from GET /v1/jobs/:id/result once result_ready is true. If the list is empty, mark the episode ready. If not, keep the episode out of your publish queue and open the file. Warnings do not cost extra and do not stop the bill: the render already ran and the minute is billed as documented at $0.10 per whole output minute, so fixing the body and re-rendering is a new charge. That is a reason to run the unbilled plan first, and a reason to keep the gate strict.

A plan cannot predict a pad or loop, because it never downloads media. The gate on the real result is the only place that warning is caught, which is why it exists.

Tuning the allowlist

Start strict: an empty EXPECTED and FAIL_FAST covering only what you have seen. Run one season, read every warning that appears, and decide for each whether it is acceptable for your content. A looped ten-second ambient clip may be fine, a looped talking head never is. Record the decision in the allowlist with a comment, and treat additions as code review items, not as quick fixes.

A worked example: episode 3 above carries output_fps_resamples_sources, so the gate refuses it. The fix is in the body, not the gate. Either set output.fps to the rate your sources share, or conform the odd source before the render. Re-run the unbilled plan, render once, and settle the episode again. The gate then prints ok and the episode joins the queue.

Add the gate to the same loop that polls job status. When a job is completed and its result is ready, run the gate immediately and write the outcome next to the episode in your tracker. Nobody has to remember to look at warnings, because a failing gate is a visible state instead of a note in a log.

Finally, log every warning code you see even when the allowlist accepts it. A code that shows up on every episode is telling you about your source material, and a code that appears for the first time is the one worth reading.