mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-09-01 19:42:03 +00:00
Vance IngallsandClaude Opus 5
a3d13e2673
de_parallel_router is present on 95.4% of render_complete events and 0.83% of render_error. Capture context itself survives failures fine (capture_mode is on 98.6% of them), so this is not renders failing before capture — the routing state specifically is being dropped. Cause is ordering. deParallelRouter is assigned twice: once before the capture-observability update, and again inside syncCapturePlan where routing is actually resolved — including the 'reverted' case, which the earlier assignment cannot know. The update in between recorded whatever was true first, so a render that failed while routed reported no routing state at all. The existing comment at the earlier call site says it is recorded there precisely so hard failures carry it; that intent was correct and the value just arrived too late. This matters for the #2840 ramp specifically. The per-install circuit breaker only arms on a revert, which requires the render to finish and self-detect — it cannot catch a crash or hang. Those are exactly the failure modes a percentage ramp exists to bound, and they were the ones telemetry could not see. Also makes the ffprobe contract sweep resilient per entry. A dangling symlink under packages/studio/data/projects threw ENOENT on stat and aborted the whole traversal, so every package sorting after 'studio' — both studio-server callers included — silently stopped being checked. main is currently red on this. The manifest assertion is what caught it, which is what it was added for. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>