heygen-com/hyperframes · error · Error

freeze failed: ${bytes.length} bytes exceeds ${MAX_FREEZE_BY

Error message

freeze failed: ${bytes.length} bytes exceeds ${MAX_FREEZE_BYTES} cap

What it means

Thrown by freezeBytes when the supplied byte length exceeds MAX_FREEZE_BYTES (256 MiB). This is the on-write half of the size cap: it checks the actual buffer length rather than a declared header, so it catches a runaway/huge payload even when content-length was absent or lied about. The cap is a deliberate guard against a hostile or runaway source filling the disk — without it a crafted manifest URL could exhaust storage during a render.

Source

Thrown at packages/core/src/figma/freeze.ts:19

/**
 * "Freeze" = write asset bytes to local disk permanently so renders never
 * re-fetch from figma (design spec §5) — not Object.freeze.
 */

import { copyFileSync, mkdirSync, rmSync, statSync, writeFileSync } from "node:fs";
import { dirname } from "node:path";

// ponytail: bound the write so a hostile/runaway source can't fill the disk.
export const MAX_FREEZE_BYTES = 256 * 1024 * 1024;

export function exceedsFreezeCap(byteLength: number): boolean {
  return byteLength > MAX_FREEZE_BYTES;
}

export function freezeBytes(bytes: Uint8Array, destPath: string): number {
  if (bytes.length === 0) throw new Error("freeze failed: empty bytes");
  if (exceedsFreezeCap(bytes.length))
    throw new Error(`freeze failed: ${bytes.length} bytes exceeds ${MAX_FREEZE_BYTES} cap`);
  mkdirSync(dirname(destPath), { recursive: true });
  // Exclusive create; on EEXIST remove and retry — never write through an
  // existing file or planted symlink (CodeQL js/insecure-temporary-file).
  try {
    writeFileSync(destPath, bytes, { flag: "wx" });
  } catch (err) {
    if ((err as NodeJS.ErrnoException).code !== "EEXIST") throw err;
    rmSync(destPath);
    writeFileSync(destPath, bytes, { flag: "wx" });
  }
  return bytes.length;
}

/**
 * Only figma-owned hosts may be frozen from a URL — render/CDN responses
 * come from figma.com subdomains or figma's S3 buckets. Blocks SSRF via a
 * crafted manifest/config URL (metadata endpoints, internal services).
 */

View on GitHub (pinned to c2996c8626)

Solutions

Reduce the render scale (opts.scale on renderNode) to shrink the asset.
Export the asset at a lower resolution from figma before importing.
If you genuinely need larger assets and accept the disk risk, raise MAX_FREEZE_BYTES in a fork — but prefer shrinking the source.
Check whether the wrong node was targeted (a parent frame export instead of a single image).

Defensive patterns

Strategy: validation

Validate before calling

import { exceedsFreezeCap } from '.../figma/freeze';
export function assertUnderCap(byteLength: number): void {
  if (exceedsFreezeCap(byteLength)) {
    throw new Error(`asset is ${byteLength} bytes — shrink it below the 256 MiB cap`);
  }
}
// usage
assertUnderCap(buf.length);
await freezeBytes(buf, dest);

Try / catch

try {
  await freezeBytes(buf, dest);
} catch (err) {
  if (err instanceof Error && /exceeds .* cap/.test(err.message)) {
    // re-render at lower scale, or skip
  } else throw err;
}

Prevention

Render figma nodes at the lowest scale that still meets quality needs.
Pre-check asset size before freezing so the error message is actionable.
Audit large figma files for oversized embedded media before bulk import.

When it happens

Trigger: Passing a large downloaded image/video to freezeBytes; an asset whose real size is > 256 MiB regardless of what its content-length header claimed; calling freezeBytes directly with a multi-hundred-MB Uint8Array.

Common situations: Importing a very high-resolution figma image at 4x scale; a figma file with an embedded video asset that exceeds the cap; bundling a project whose LUT or texture is unexpectedly huge.

Related errors

AI-assisted analysis of heygen-com/hyperframes@c2996c8626 (2026-08-12). Data as JSON: /api/errors/a540bb631c618d13. Report an issue: GitHub.