Skip to content

fix(cli): a failed render names its failure code for the Desktop app - #6725

Merged
miguel-heygen merged 1 commit into
mainfrom
fix/render-failure-code
Oct 29, 2026
Merged

miguel-heygen merged 1 commit into
mainfrom
fix/render-failure-code

Conversation

@miguel-heygen

Copy link
Copy Markdown
Collaborator

Description

When a render fails, the Desktop app records why from the CLI's error text, and it can only find a code when the text carries one in brackets ([VIDEO_SOURCE_UNRENDERABLE; ...]) or names a network error. Many failures carry neither: a composition that never reports a duration, an error thrown in the page, a file error like ENOENT or EPERM, or a correctness warning, whose code the CLI prints in lowercase. Those exports reached Desktop's telemetry as reason "unknown" with no code. On Windows, three of the last four failed Desktop exports looked like that.

The CLI already prints a versioned, content-free @hf-diagnostic line for Desktop when a render fails with audio failures. Every failed render now prints it, with a code from a fixed list, built from the error's type rather than its words:

Failure Code
Render blocked by a correctness warning the warning's code, upper case (AUDIO_PROCESSING_FAILED, SUB_TIMELINE_SCRIPT_FAILURE, ...)
A code the CLI already prints in brackets that code (VIDEO_SOURCE_UNRENDERABLE, ...)
A file error, on the error or its causes or in its message ENOENT, EPERM, EACCES, EBUSY, ENOSPC, EMFILE, EISDIR, ENOTDIR, EEXIST, EXDEV
A composition that reports no duration COMPOSITION_ZERO_DURATION
A capture failure with page errors PAGE_ERROR
Any other capture failure CAPTURE_ plus its kind (CAPTURE_PROTOCOL_TIMEOUT, CAPTURE_IO, ...)
Anything else RENDER_FAILED

The line never carries the error's words, which can name the person's files and folders. It stays silent in a terminal, as before. Desktop reads it in a follow-up once a release carries it.

Testing

fails without the fix: names a failed render's code without its words (8 cases) in packages/cli/src/ui/renderDiagnostic.test.ts. On main a failure without audio failures prints no line.

  • packages/cli/src/ui/renderDiagnostic.test.ts: 21 passed, 3 runs in a row; each case also checks that private text in the error never reaches the line.
  • CLI tsc --noEmit, format, comment ratchet: clean.

What I did NOT exercise

  • Render failures before the pipeline starts (preflight checks, the Docker image build, an encoder that is missing) exit elsewhere and print no code yet.
  • A real Desktop export reading the line: Desktop does not read it until its follow-up.

@github-actions

Copy link
Copy Markdown
Contributor

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

  • resize-none-px-r0-root-z100: tracking 0.06, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo true, teleport true / tracking 0.06, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo true, teleport true / tracking 0.06, pressJump 0, drop 0, reload 0, 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 heygengenesis Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verdict: APPROVE · 0 blocker · 0 important · 1 nit · head 5638affd

All runs on this head are green, including Windows render verification. The 8 named cases pin the code and check that the private text never reaches the line. On main, a failure with no audio failures prints no line.

Scope

Read both files. The only caller is handleRenderError (render.ts:1794), so the line stays silent in a TTY and under --quiet as before. CAPTURE_<kind> and the quality-warning codes come from fixed unions.

— Genesis

"EXDEV",
];
const FILE_ERROR = new RegExp(`\\b(${FILE_ERRORS.join("|")})\\b`);
const CLI_CODE = /\[(?!(?:DEBUG|INFO|WARN|ERROR)\b)([A-Z][A-Z0-9_]{2,63})[\];]/;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: CLI_CODE runs first and takes any bracketed upper-case token in the message, so the list isn't strictly fixed. [HDR] No Chrome binary found (hdrCapture.ts:245) reports HDR. A page error carrying [ACME_LAUNCH] would put that token on the line ahead of PAGE_ERROR. Desktop's renderFailure.mjs:72 already scrapes the same pattern from stderr, so this adds no new exposure. Matching only codes the CLI defines would make the "fixed list" claim hold.

@miguel-heygen
miguel-heygen added this pull request to the merge queue Oct 29, 2026
Merged via the queue into main with commit ba8ffff Oct 29, 2026
71 checks passed
@miguel-heygen
miguel-heygen deleted the fix/render-failure-code branch October 29, 2026 07:55
SanHsien added a commit to SanHsien/hyperframes that referenced this pull request Nov 7, 2026
…-com#7336-heygen-com#7358

Adopt heygen-com#7304 (without CLI renderDiagnostic, needs heygen-com#6725), heygen-com#7331, heygen-com#7332, heygen-com#7334,
heygen-com#7337, heygen-com#7336, heygen-com#7339, heygen-com#7289, heygen-com#5594, heygen-com#6900, heygen-com#7322, heygen-com#7342, heygen-com#7343, heygen-com#7350 (onProgress
only), heygen-com#7352, heygen-com#7348, heygen-com#7344, heygen-com#7353, heygen-com#7356 and heygen-com#7355. Defer heygen-com#5708 (needs heygen-com#6911) and
heygen-com#7345 (READ_VERSION 4 vs 7); heygen-com#7307 not applicable. Re-read 14 moved pins, pin 6
new PRs (monitored 126). Make checkReportFile module-private and suppress the
cross-package closeTestChrome duplicate for fallow.

Co-authored-by: Miguel Ángel <[email protected]>
Co-authored-by: SophiaHuangCc <[email protected]>
Co-authored-by: Dante <[email protected]>
Co-authored-by: Muzzy5150 <[email protected]>
Co-authored-by: ump45nose <[email protected]>
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant