[miguel-heygen]

What

When a capture stall is recovered during a streaming render, the render now continues from the first frame not yet written to the encoder. Before, every streaming path except one restarted the whole film at frame 0 on a fresh encoder, so a stall near the end of a long film cost the whole film again, and a second stall ended the export.

Why

The streaming stage already resumed after a stall in one place: the parallel BeginFrame path, once. Everywhere else the stall error left the stage, the orchestrator forced a fresh screenshot session, and the stage ran again from frame 0.

A frame's pixels depend on its index and time, not on the frames before it, and the encoder already holds every frame it was given in order. So the stage keeps its encoder, opens a fresh capture session in the same mode, and continues at the first unwritten frame. The parallel path's "where to resume" (the count written to the encoder) is the single rule; the sequential paths now use the same one.

How

• Parallel streaming: the resume gate no longer requires BeginFrame and no longer stops after one resume. A resume needs new frames written since the last one.
• Sequential streaming (plain loop and the drawElement worker-encode loop): the session lifecycle runs in a loop with a resume cursor. A stall with frames written since the last resume closes the wedged session, opens a fresh one, and both loops start at the cursor. The worker-encode loop resumes at the first frame not yet drained, not the one captured but unwritten.
• A stall before any frame was written, or a resume that lands no new frame, throws as before, so the orchestrator's existing fallback (and the end of the render) is unchanged. No endless loop: each resume needs progress.

Not changed: the disk capture path already retries only missing frames; the HDR and segmented stages are separate.

Test plan

• Unit tests added/updated (captureStreamingStage.test.ts, 38 tests, bun test)
• Manual testing performed: end to end on a Linux box, below
• Documentation updated (not applicable)
• Comments follow CONTRIBUTING.md "Comments"

fails without the fix: a sequential capture stall after frames were written > resumes a screenshot capture at the first unwritten frame, not frame 0 (and the BeginFrame, drawElement worker-encode and parallel screenshot / drawElement siblings). At the merge-base 8 tests fail and 30 pass; at this head 38 pass, 3 runs in a row. Each new test also fails when its own code is broken: sequential resume at 0, the worker-encode loop restarting at 0, resuming without new frames (sequential and parallel), parallel resume for BeginFrame only, parallel resume once only.

End to end: a 60 s, 1800-frame 1080p30 film (GSAP text plus a video layer), rendered uninterrupted and again with the whole render process tree frozen for 100 s at about frame 714, so the 60 s watchdog fires.

path	uninterrupted	stalled at	resumed at	stalled output
sequential, BeginFrame	d5c169d7…7125140	713	716	same file hash
sequential, screenshot	same	714	716	same file hash
parallel streaming (2 workers), screenshot	same	715	716	same file hash

All six renders have one SHA-256, d5c169d758d073d686d4aab7dc40bfccc1d633d3cc086f0210441b9db7125140, so the stalled renders are byte-identical to the uninterrupted ones.

What I did NOT exercise

• drawElement end to end (the box has no GPU path for it); it is covered by the unit tests only.
• A stall in a render with a video layer's late frames or the drawElement risk-frame screenshot session after a resume.
• Real sleep or a real GPU hang; the freeze is a stand-in that trips the same watchdog.

[github-actions]

Edit accuracy: accurate 267 (base branch 267), smooth 82 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (8)

• seqplainkeys-none-center-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-center-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): fail / pass / pass, passes
• seqplainkeys-none-center-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-pct-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-pct-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-px-r30-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run

Unstable (2)

• seqplainkeys-none-pct-r0-nested-z100: tracking 0.05, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo false, teleport true / tracking 0.05, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo true, teleport true / tracking 0.05, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo true, teleport true
• seqab-none-pct-r0-root-z100: tracking 0.05, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true / tracking 0.05, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true / tracking 0.05, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true

[heygengenesis]

Verdict: APPROVE · 0 blocker · 1 important · 0 nits · head 067dbd1e

The fails without the fix line holds. With main's captureStreamingStage.ts and this head's tests, 8 tests fail and 30 pass; at head all 38 pass. The sequential path continues from the last frame written to the encoder, which is safe because the stall race wraps only the capture call, never writeFrame. The worker-encode loop resumes at the last frame it drained, and a stall's orphaned capture never reaches the encoder. One important item is inline.

Scope

Read the stage diff end-to-end, plus raceAgainstStall, stallBudgetMs and the orchestrator's stall fallback (renderOrchestrator.ts:5134). Windows render verification failed on an unrelated engine test (browserManager.test.ts resolveHeadlessShellPath, a 5 s timeout); it passed on rerun. preview-regression was cancelled at checkout and passed on rerun. CI's File size check job was cancelled even though all of its steps passed. Producer unit and integration tests, regression, Comments and CodeQL are green. No prior reviews.

[heygengenesis]

important: resumes now have no upper limit. Each resume only needs one new frame, so a page that wedges every few frames keeps resuming in the same mode. Each resume costs a full stall budget plus a new session: 1800 frames with a stall every 10 frames is about 180 × 60 s. Before, the first stall went to the orchestrator's fresh-screenshot fallback, which may not wedge at all. Consider a cap (for example, at most 2 or 3 resumes per stage) after which the stall is thrown, in both this check and the parallel one at :935.

[miguel-heygen]

Fixed in 0338499: resumes are capped at 3 per stage (STALL_RESUMES_BEFORE_FALLBACK), in both the sequential check and the parallel one. A fourth stall throws the typed stall even when new frames landed, so the orchestrator's fresh-session fallback runs as before. New tests drive four stalls in a row in each path and expect three resumes, then the typed stall; both fail with the cap removed (38 pass, 2 fail) and pass at head (40 of 40, 3 runs). oxlint, oxfmt and tsc exit 0.

[heygengenesis]

✅ Fixed in 0338499

[heygengenesis]

Verdict: APPROVE · 1 resolved, 0 open, 0 new · 067dbd1e → 03384995

The resume cap is in place in both paths. With the cap removed, the 2 new tests fail; at head all 40 pass. Every check is green on this head.