mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-09-03 12:54:29 +00:00
Via
58cff5f6d5
Field signal ts=1784146416 (darwin/arm64, CLI 0.7.58, 7/10): host page.goto hit Navigation timeout of 60000ms twice on a CSS 3D + audio composition; Docker rendered the same composition successfully. Puppeteer's stock "Navigation timeout of 60000 ms exceeded" text names none of HyperFrames' existing escape hatches, so the reporter had no signal that the failure had knobs. Wraps main-render Puppeteer `page.goto` errors matching /Navigation timeout|net::ERR_TIMED_OUT/i with an augmented message that names: - The effective timeout currently applied (`cfg.pageNavigationTimeout`). - Raise-the-timeout: `PRODUCER_PAGE_NAVIGATION_TIMEOUT_MS` env, `--browser-timeout` CLI flag (seconds). - Browser-binary escape hatch: `HYPERFRAMES_BROWSER_PATH` env. - Field-signal shape: darwin/arm64 + CSS 3D + audio compound Docker hint — gated on all three inputs being explicitly true; falls back to generic hints when any input is unknown. Mirrors #2443's HYPERFRAMES_BROWSER_PATH surfacing pattern (which covered download-time failures) at the runtime `page.goto` layer. Non-matching errors flow through unchanged. Original error preserved via `err.cause`. Wired into `renderOrchestrator.executeRenderJob`'s top-level catch, composed after `augmentProtocolTimeoutError` so the two augmenters never both fire on the same error (mutually exclusive regexes). Current wire-up passes no `hasCss3D` / `hasAudio` context — no compile-time CSS-3D signal is threaded through the render pipeline, and `hasAudio` is block-scoped inside the try. Per the helper's fallback docs, unknown flags route to the generic env + browser-path hints. A future compile-time CSS-3D scan can thread both flags to enable the full compound Docker hint without touching this helper's signature. Stack: PR #3 of 9 (base via/win32-streaming-encode-autodisable). Signed-off-by: Via <vance@heygen.com>