Diagnosing a Stalled Render: Scene States, Stuck Flags, Resume

A multi-scene render stops moving and the instinct is to cancel the whole thing and kick it off again. That instinct is expensive, and it's usually wrong. A run that's eight scenes deep with six already finished doesn't need to redo those six — it needs whatever's actually stuck to be identified and reset, which is a completely different, much cheaper operation than starting over. The reason people default to the restart anyway is that it's the only move available if you can't actually see what state each scene is in. Once you can, "start over" almost never comes up.

The state machine underneath a run

Every scene in a video workflow run moves through a fixed set of states: pending, generating_image, generating, and then one of three end states — completed, failed, or cancelled. That's it. There's no hidden "processing" limbo — a scene is always in exactly one of these, and knowing which one is the entire diagnostic.

State	What it means
pending	Queued, not yet dispatched to a generation provider
generating_image	An image-generation step is in flight for this scene (for workflows that generate a reference frame first)
generating	The main video generation is in flight
completed	Done — output exists and is usable
failed	The generation attempt errored out
cancelled	Deliberately stopped, by you or by cancelling the run

A run that "looks stalled" from the outside is really just one or more scenes sitting in generating_image or generating for longer than expected, while the scenes before and after them may be in completely different, perfectly fine states. Treating the whole run as broken because one scene is slow is the exact assumption that leads to an unnecessary full restart.

What "stuck" actually means

"Stuck" isn't a state a scene gets assigned and stored — it's computed on demand. A scene sitting in generating_image or generating for more than 10 minutes without any update gets flagged as stuck when you check the run; a scene that's been generating for 3 minutes is just... generating, not stuck, even though from the outside both look identical: a spinner, no output yet. That distinction matters, because it means checking a run early tells you nothing about whether it's actually in trouble — the 10-minute threshold exists specifically so a normal generation in progress doesn't get misread as a failure.

Reading the run before touching anything

The diagnostic step is asking the agent directly — "Why did my last workflow run stop? Which scene failed?" — which calls get_workflow_run_scenes against your run. It returns the full scene-by-scene breakdown: each scene's order, its current status, the provider request ID behind it, an error message where one exists, timestamps for when it started, last updated, and finished, and the derived stuck flag described above. It also returns a trimmed content preview per scene — the scene name, a prompt snippet, a voiceover snippet, caption and overlay counts — plus the actual image or video URL once a scene has completed, so you're looking at what each finished scene actually produced, not just a status word.

Checking is free, and it's the step that turns "the video generation seems broken" into something specific: scene 4 has been in generating for 22 minutes with no update, scenes 1 through 3 are completed with real output attached, and scenes 5 through 8 are still pending, waiting on scene 4. That's an actionable picture. "It's stuck" on its own isn't.

What resume actually does

resume_workflow_run is a narrow, specific operation, and knowing exactly what it touches is what makes it safe to reach for readily. Given a run_id — and an optional stale_minutes threshold, 10 by default — it finds scenes stuck in generating_image or generating whose last update is older than that threshold, resets the earliest stuck one back to pending, clears its stale provider request ID so a fresh dispatch isn't confused by the old one, and triggers the scheduler to dispatch the next ready scene. It does not touch completed scenes, does not touch scenes that are still legitimately in progress within the threshold, and does not re-run anything that already finished.

That last point is the direct answer to the credits question: resuming a stuck scene doesn't re-charge scenes that already completed. The expensive assumption behind "just restart the whole run" — that fixing one broken scene means redoing everything — is specifically the thing this tool exists to avoid. It's also safe to call speculatively: on a run where nothing is actually stuck, it no-ops rather than doing anything destructive, so checking "is this stuck" and immediately trying to resume costs nothing extra if the answer turns out to be no.

A triage runbook

1. Check before assuming. Ask the agent which scene, if any, is actually stuck — don't cancel or restart based on a spinner alone. This is the free step and it's the one that tells you whether you have a real problem or a normal wait.
2. Resume if a scene is genuinely flagged stuck. This resets only the earliest stuck scene and re-triggers dispatch — safe to try even if you're not fully sure, since it does nothing on a healthy run.
3. Re-check after resuming, rather than assuming it worked. If the same scene gets flagged stuck again on a second pass, that's a different problem than a transient provider stall — worth looking at the scene's actual prompt and content before resuming a third time.
4. Escalate to force only when repeated resumes aren't landing. The tool exposes a force parameter for exactly this case — a scene that keeps stalling isn't behaving like ordinary provider latency anymore, and worth treating differently rather than resuming on a loop.
5. Cancel outright if you no longer want the output. "Cancel that workflow run, I don't need it anymore" stops the run and every in-flight scene immediately — the right move when the job itself is no longer wanted, as opposed to a job you want that's just temporarily stuck.

When resume isn't the real fix

A scene that gets flagged stuck once and clears on resume is almost always a transient provider-side delay — nothing about your setup was wrong. A scene that stalls the same way two or three resumes in a row is telling you something different: the prompt, reference image, or specific combination of settings on that scene may be triggering a slow or failing path on the provider's end that a fresh dispatch alone won't fix. At that point, the content preview get_workflow_run_scenes already returns — the prompt snippet, the voiceover snippet — is exactly what to review before resuming again, since the fix is more likely a scene edit than a fourth retry.

Running this in Versely

Multi-scene runs are exactly what a backgrounded, multi-step task produces — the kind spawned when you hand the agent a job that runs asynchronously while you keep working, like a movie built scene-by-scene or a bulk generation batch. When one of those stalls, the fix lives in the same conversation: ask what's stuck, resume if something is, and re-check rather than guessing. The full check-or-resume flow covers the exact tool sequence, and any run worth diagnosing this carefully is usually worth saving — once it's finished, turning it into a reusable workflow means the next run starts from a known-good recipe instead of a blank prompt.

FAQ

Does restarting a stuck run from scratch cost more than resuming it?

Yes, in the case that matters most — a run partway through, with some scenes already completed. Resuming resets only the specific stuck scene and doesn't re-charge scenes that already finished, while a full restart regenerates everything, including the scenes that were already done and paid for.

How do I know if a scene is actually stuck versus just taking a while?

A scene only counts as stuck once it's spent more than 10 minutes in an active generating state without any update — that threshold exists specifically so a normal generation in progress isn't misread as a failure. Checking the run's scene breakdown shows you the actual elapsed time and status rather than leaving you to guess from a spinner.

Is it safe to try resuming a run if I'm not sure anything is actually wrong?

Yes — resuming a healthy run with nothing stuck simply does nothing. The tool only acts on scenes that meet the stuck threshold, so checking and attempting a resume costs nothing extra if it turns out there was no problem to begin with.

What should I do if the same scene keeps getting stuck after multiple resumes?

Treat it as a different problem than ordinary provider delay. Review that scene's actual prompt, reference image, or settings — available in the same scene breakdown as a content preview — since a scene that stalls repeatedly is more likely to need a content change than another retry.

Can I cancel just one scene instead of the whole run?

The cancel operation stops the run and every scene still in flight together, rather than targeting a single scene. If only one scene is problematic and the rest are fine or already completed, resuming that specific stuck scene is the more targeted move; cancelling is for when you no longer want the run's output at all.

Next time a run stalls, ask first: check what's actually stuck before cancelling anything — resuming the one scene that needs it costs nothing extra and keeps every completed scene's credits intact.