mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-09-03 04:38:33 +00:00
fix(engine): fail-fast the sub-composition timeline wait when a script 404s
pollSubCompositionTimelines waits for every [data-composition-id] host to
register window.__timelines[id]. When the script carrying that registration
fails to load (404 / request failure), the registration can never arrive —
but the poll still burned the full playerReadyTimeout (45s), then warned and
shipped a silently animation-less render. Wild scale: the capture-setup
histogram over 30 days of local renders decays smoothly (402/503/364/282/191
per 5s bucket) then spikes to 705 at the 45s bucket — ~1,000 renders/month
across 402 distinct users, ~15 user-hours of pure waiting.
- Sessions now record failed SCRIPT resources (requestfailed + HTTP>=400
response, listeners that already existed for diagnostics) in
session.scriptLoadFailures.
- pollSubCompositionTimelines takes a failure getter and cuts the wait to a
2s grace once any script failed, with a loud warning naming the URL(s).
Late-registering fetch-async comps are unaffected: no script failure means
the full timeout still applies, and a registration landing inside the
grace window still wins (tested).
- Outcome telemetry: session.subTimelineWaitOutcome ("ready" | "timeout" |
"script_failure") -> CapturePerfSummary -> RenderPerfSummary.subTimelineWait
(worst across sessions) -> render_complete sub_timeline_wait, so the wild
rate becomes directly trackable instead of setup-histogram forensics.
Validation: the discovery comp (0768f038, its animations.js unreachable)
drops from ~72s to 23.1s total — poll cut at 2.1s with the script named;
healthy comp reports "ready". Canary suite 7/7 (PSNRs identical). 4 new
poll unit tests; engine suite 907 passed (14 failures are PRE-EXISTING on
main at v0.7.42 — 18 fail on a clean checkout, stash A/B verified).
tsc/oxlint/oxfmt clean.
Corpus note: 258/1,762 corpus comps (14%) reference local scripts missing
from the corpus fetch — their historical eval INIT timings measured this
timeout, not the engine. Capture-stage ratios remain valid (both paths paid
it equally).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Fable 5
parent
230cc5bf7d
commit
54359f3d6a
@@ -1708,6 +1708,7 @@ function trackRenderMetrics(
|
||||
speedRatio,
|
||||
captureAvgMs: perf?.captureAvgMs,
|
||||
captureP50Ms: perf?.captureP50Ms,
|
||||
subTimelineWait: perf?.subTimelineWait,
|
||||
videoCount: perf?.videoCount,
|
||||
capturePeakMs: perf?.capturePeakMs,
|
||||
tmpPeakBytes: perf?.tmpPeakBytes,
|
||||
|
||||
@@ -148,6 +148,7 @@ export function trackRenderComplete(
|
||||
captureAvgMs?: number;
|
||||
/** Warmup-robust per-frame capture median (basis for speedup estimates). */
|
||||
captureP50Ms?: number;
|
||||
subTimelineWait?: string;
|
||||
/** <video> element count (speedup segmentation: injection comps read lower). */
|
||||
videoCount?: number;
|
||||
capturePeakMs?: number;
|
||||
@@ -221,6 +222,7 @@ export function trackRenderComplete(
|
||||
speed_ratio: props.speedRatio,
|
||||
capture_avg_ms: props.captureAvgMs,
|
||||
capture_p50_ms: props.captureP50Ms,
|
||||
sub_timeline_wait: props.subTimelineWait,
|
||||
video_count: props.videoCount,
|
||||
capture_peak_ms: props.capturePeakMs,
|
||||
peak_memory_mb: props.peakMemoryMb,
|
||||
|
||||
Reference in New Issue
Block a user