[miguel-heygen]

What

The BeginFrame start-up check of each capture browser now keeps asking for the first frame until its own 2 s deadline, instead of giving up after 10 tries (about a quarter of a second). A chunk whose workers still end up in different capture modes keeps failing with a typed error.

Why

A chunk is captured by several workers, each with its own browser, and each browser runs this check at start-up. Under CPU load a fresh renderer can take longer than 10 quick tries to draw its first surface; the check then reported "BeginFrame not supported" after 246 ms, although its deadline is 2 s, and that one worker fell back to screenshot mode while the others stayed on BeginFrame. The chunk then failed with capture workers reported invalid or inconsistent modes: beginframe,screenshot and only the state machine's retry recovered it, about one extra chunk run. Seen once in 1,230 browser launches (six 30-minute renders, 204 chunks each, on a Lambda stack).

Related work

Nothing overlapping.

How

• probeBeginFrameSupport loops until a PNG arrives or the probe deadline passes, instead of for a fixed 10 tries. A browser that truly lacks BeginFrame still falls back, after at most the same 2 s deadline.
• The post-capture mode check is now observedChunkCaptureMode, which throws a typed MixedCaptureModesError for a mix. It is a hard failure on purpose: retrying in BeginFrame (the state machine's retry) beats forcing the chunk into the slower screenshot mode, and the cause is now rare.

Test plan

• Unit tests: a renderer that draws its first frame on the 26th try is now supported (fails on main, which gives up at 10); an always-empty renderer is still reported unsupported, at the deadline; a mixed chunk fails with the typed error and is not retried in screenshot mode.
• Real Chrome, N browsers started at once on 6 CPUs, interleaved before/after builds (shared test machine): 12 at once, 1 of 288 browsers fell back before and 0 of 288 after; 6 and 16 at once saw no fallback in either build (450 and 960 launches each). At 24 at once on 6 CPUs the machine is saturated and both builds hit the 2 s deadline.
• Documentation updated (not applicable)
• Comments follow CONTRIBUTING.md "Comments"

[github-actions]

Edit accuracy: accurate 271 (base branch 271), smooth 143 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 (0)

Unstable (2)

• seqheldtwice-tlhold-px-r0-root-z100: tracking 120.29, pressJump 312.3, drop 0, reload 0, render 0.02, renderKey -, undo true, teleport false / tracking 0.13, pressJump 0.11, drop 0.07, reload 0.07, render 0.02, renderKey -, undo true, teleport true / tracking 0.13, pressJump 0.11, drop 0.07, reload 0.07, render 0.02, renderKey -, undo true, teleport true
• seqplainkeys-none-pct-r0-root-z100: tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo false, teleport true / tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true / tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true

[heygengenesis]

Verdict: REQUEST CHANGES · 1 blocker · 0 important · 0 nits

The logic is fine. The only problem is that the Comments workflow fails on the comment-share ratchet for browserManager.ts (see inline). Cut that line and this is an approve.

Scope

Read all 4 files at 71b05162. Checked: the probe runs only for linux headless-shell BeginFrame launches. A truly unsupported build still falls back by the same 2 s deadline (now about 2 s instead of about 0.25 s per launch, as the PR states). MixedCaptureModesError still gets the SAM RenderChunk States.ALL retry (×4), so the new error name does not drop the state-machine retry the PR relies on. shouldRetryChunkCaptureWithScreenshot returns false for it, as pinned. Nothing matched on the old message text. Other CI jobs were still running when this was posted. No prior reviews.

[heygengenesis]

blocker: this line fails Comments ("RAISED comment share: browserManager.ts is 14.2% (178/1251), at the base 14.2% (177/1250)"). The ratchet allows a file's comment share only to go down. The test name and the probe's new after N attempts in Xms detail already carry the reason:

Suggested change

// A renderer under load can take longer than a fixed count of tries to draw its first surface.

[heygengenesis]

✅ Fixed in 0b40f3c

[heygengenesis]

Verdict: APPROVE · 0 blocker · 0 important · 0 nits — 1 resolved, 0 open, 0 new · 71b0516 → 0b40f3c. The delta is the one-line removal, and Comments is green. The one Windows engine-cli failure is audioMixer.urlRead.test.ts timing out at 5 s. This PR touches no audio code, so that failure is unrelated.