Build a video render queue with visible job states

Make job state visible

A queue is useful when someone can tell what is waiting, what is running and what needs attention without reading a terminal transcript. Define the job states and allowed transitions before adding workers. Then decide how workers claim jobs and how the operator identifies the exact output produced by a completed task.

In our production in October 2026, heavy renders are staged and checked before later steps use their outputs. The queue design here is a recommended implementation method. claude for ads gives the broader Claude context. FFmpeg documentation describes the media command, while Claude Code permissions describe execution authority. Neither substitutes for a job-state contract.

Consider two local workers polling a hypothetical mug ad queue. Both may see the same waiting job, but only one should acquire its claim. The job already identifies its recipe and output requirements, so execution does not depend on whichever worker arrived first. If that worker stops, retain the attempt record and inspect any candidate file. Recovery is a state transition with evidence, rather than another worker quietly overwriting an unexplained output.

Record job ID, recipe hash, source manifest, intended output, requested operation and submission time. The worker should receive a definite recipe, not a path whose contents can change while the job waits. Keep the job’s revision separate from the video’s approval status.

Validate required fields and media before accepting the job. If an input is missing, return a readable failure rather than leaving the job pending indefinitely. A pending state means ready work awaiting a worker, not an unresolved production brief. Validate AI video ad outputs before human review covers output validation gates. Keep their results attached to the same recipe and output identities the queue uses.

Source: Turntake editorial checklist (proposed), October 2026.

Claim one job atomically

Use a claim operation that only one worker can win. A sequence that separately checks “pending” and then writes “running” can allow two workers to begin the same job. The exact locking mechanism depends on the storage system, but the ownership result should be unambiguous.

Record worker identity, claim time and an attempt number. Give each attempt a separate working directory. A worker should not modify another worker’s temporary output or infer ownership from a familiar filename. These are proposed concurrency controls. They help distinguish a legitimate retry from two simultaneous processes rendering into the same path.

1. 01Accept fixed jobValidate inputs
2. 02Claim atomicallyAssign one worker
3. 03Render temporary outputRespect resource limits
4. 04Validate and completeRecord output hash

Bound concurrency by actual resources

Set a maximum number of active renders and a temporary-disk allowance. A machine can become less productive when several large filter graphs compete for memory and storage. Keep the chosen limits in the operator configuration rather than burying them inside worker prompts.

In our production in October 2026, parallel workers receive isolated folders and limits. Apply that principle to renders as well. A worker needs the recipe, readable assets and a temporary output location; it does not need an ad-account tool or authority to generate a missing clip. Return missing production ingredients to their owner. Can Claude edit video ads? Render from an edit file covers the narrow editing job that a queue may execute.

Publish output only after validation

Render to a temporary path owned by the attempt. Check expected streams, duration, required layers and a readable media result before moving it to the completed output location. A process exit code alone should not change the job to complete.

If validation fails, record the failed check and preserve enough evidence for diagnosis. Do not leave a partial file at the final path where another process may consume it. A completed job should identify the validated output hash and the validator result. The editorial reviewer can then inspect that concrete file while the queue remains responsible only for execution and machine checks.

Queue stateMeaning

• Queue statePendingMeaningValid work awaits a worker
• Queue stateRunningMeaningNamed attempt owns execution
• Queue stateCompleteMeaningValidated output is identified
• Queue stateFailedMeaningLocated error needs action

Recover an interrupted own job deliberately

When a worker disappears, inspect its recorded attempt and current process state before reclaiming work. A stale timestamp is a signal to investigate, not automatic permission to overwrite another attempt. If the render finished but the state update failed, validate the existing output before deciding whether another render is needed.

Keep recovery actions logged. Record whether the attempt resumed a stage, accepted an existing validated file or started a new attempt. Retry AI generation jobs without submitting twice covers external generation request state, which must remain separate: a stopped local render and a remote provider job have different recovery questions. Do not use the queue’s retry action to resubmit external generation blindly.

Deliver compact failure information

A useful failure record contains job ID, attempt, stage, failed property, relevant log excerpt and next action. Avoid an unreadable dump of every media probe field when the defect is simply a missing audio stream. Keep secrets out of the logs.

Turntake’s model plans describes Turntake’s model plans. This queue is a studio architecture method, not a claim that a new Turntake self-service render service is available.

For a proposed acceptance test, start two workers against one pending fixture and require one claim. Then interrupt the winning worker after it writes a temporary file. Recovery should inspect the attempt, keep the partial output away from consumers and create a new validated result or a clear failure. This tests ownership and completion boundaries rather than only the easy path where one command succeeds.

Separate retry policy from user intent

A queue can retry a technical stage within its documented policy, but it should not invent a new creative operation to make the job succeed. If the requested source clip is missing, returning a failure is clearer than selecting another clip automatically. If a required label is unsupported, report that operation. Keep the requested recipe unchanged across technical attempts. A new editorial choice becomes a new job revision, making the distinction between recovery and changed intent visible in the queue.

Who wrote this We made the ads first, for SmartSolar in Denmark, Sweden and Ireland. Then we built Turntake. Where Turntake comes from