[miguel-heygen]

What

A render no longer waits 45 s at setup for a composition that has no script able to register a timeline, for example a scene drawn on a canvas or driven by requestAnimationFrame.

Why

The readiness poll waited for window.__timelines[id] on every data-composition-id host without data-no-timeline. A composition that never registers one (the lint rule already warns about this) sat out the whole playerReadyTimeout, on every render, in every capture worker, then finished with a sub_timeline_readiness_timeout warning. The wait is only worth paying when something might still register a timeline.

How

pollSubCompositionTimelines now first asks the page whether any author script can register a timeline (authorScriptsMayRegisterTimelines): every inline, template and same-origin script is read and none mentions __timelines. If none can, the composition is ready at once. A module script, any code that imports another file (import or import()), a cross-origin or unreadable script, or a page that is still loading answers "may register", so those still wait as before.

A page that already has a script error or a script that failed to load keeps the old wait, so the failure is still reported as sub_timeline_script_failure rather than the page passing as ready. The readiness check runs first and the script scan runs once per page.

The compiler's scope wrapper mentions __timelines itself, so wrapScopedCompositionScript and the module prelude now delimit the authored source (AUTHORED_SOURCE_BEGIN / AUTHORED_SOURCE_END) and the scan reads only that part.

Design call: the options were (a) a shorter timeout (rejected: it still taxes every such render and cuts off slow registrations), (b) treat every cross-origin script as non-registering (rejected: a late registration would silently render without its animation; for the same reason a registration inside an imported file counts as possible), (c) read what the author scripts say and wait only when one can register (chosen). Remaining limit: a composition whose scripts come from another origin keeps waiting unless its host says data-no-timeline.

Tests

• frameCapture-subTimelinePoll.test.ts: a page with no registering script is ready at once instead of waiting out a 60 s timeout; the scan is false for scripts that never mention a registration (inline, template, same-origin file), ignores the runtime, reads only the authored part of a scoped wrapper, and answers true for a registering, module, importing, unreadable or cross-origin script. Fail on main (the function and the early exit do not exist).
• scriptFailureAttribution.test.ts: its compositions now carry a registrar that is defined and never called, which is what a registration that never arrives looks like.
• compositionScoping.test.ts: the wrapper puts exactly the authored source between the markers.
• 3 runs of the sub-timeline suites: 39/39 each; core compiler suites 635/635.

Measured

Fixture: a root audio clip plus a sub-composition drawing on a canvas with requestAnimationFrame, no timeline, 6 s at 1280x720, software GL, same box and same render.

	setup	total render
released 0.8.202	46.7 s	53.7 s
this PR, 2 runs	1.7 s, 1.6 s	7.9 s, 7.4 s

The audio mix is unchanged (the clip window reads -23.0 dB before and after).

[heygengenesis]

Verdict: REQUEST CHANGES · 2 blocker · 0 important · 1 nit · head cdc5d082

• blocker — CI Producer: integration tests fails: scriptFailureAttribution.test.ts has 18 of 22 failing (expected [] to deeply equal [ 'sub_timeline_script_failure' ] / [ 'sub_timeline_readiness_timeout' ]). The scan short-circuits readiness before the fail-fast and timeout paths run, so a composition whose scripts throw now gives no warning at all. Either keep those paths reachable when a page error or script-load failure is present, or re-baseline the tests with a reason. ↓ 404 inline
• nit — the scan runs before the cheap readiness expression on every 150 ms poll and re-fetches every same-origin script each time. Evaluate the expression first, or cache the scan once readyState is complete.

Scope

Read all 7 files and both pollSubCompositionTimelines call sites (the __name shim is installed on both pages). Locally: core compiler 635/635, including goldens; engine frameCapture 326/326. Comments (not required) fails: comment share rose in compositionScoping.ts. 6f3543e was superseded by cdc5d08 before this review.

[heygengenesis]

blocker — fetch resolves on a 404, so a missing project script reads as "cannot register" and the composition is ready at once. Before this change, <script src="scene.js"> with a typo'd path failed fast with sub_timeline_script_failure. Now it renders a frozen scene with no warning (this is the a script from the project is missing case in scriptFailureAttribution.test.ts). The unit test stub throws on a missing file, but a real fetch doesn't.

Suggested change

	if (mayRegister(await (await fetch(url)).text())) return true;
	const response = await fetch(url);
	if (!response.ok || mayRegister(await response.text())) return true;

[heygengenesis]

✅ Fixed in e138bd1: a recorded script-load failure, a 404 included, now keeps the wait. I checked it against the original fixtures (without the added registrar), and a script from the project is missing still ends in sub_timeline_script_failure.

[github-actions]

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

• seqplainkeys-none-center-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: APPROVE — 2 resolved, 0 open, 0 new · cdc5d08 → e138bd1. A failed script or page error now keeps the wait, the scan runs after the readiness check and only once per page, and all CI is green.

Note

I re-ran scriptFailureAttribution.test.ts without the new registrar line. All 8 sub_timeline_script_failure cases pass, the 404 one included. The 10 cross-origin widget cases end with no warning instead of sub_timeline_readiness_timeout. That's the intended trade: no script can register a timeline, so the frames match and only the 45 s wait and its warning are gone. The fixture comment says so.