remotion-dev/remotion · error · Error

Renderer S3 status identifies chunk ${String(status.chunk)},

Error message

Renderer S3 status identifies chunk ${String(status.chunk)}, attempt ${String(status.attempt)}; expected chunk ${expectedChunk}, attempt ${expectedAttempt}

What it means

The status object repeats the chunk and attempt it belongs to, and its S3 key embeds them (.../chunks/{chunk}/attempt-{attempt}/status.json). parseS3RendererStatus() requires the embedded status.chunk and status.attempt to equal the chunk/attempt being polled. A mismatch means the file at this key describes a different chunk or retry attempt than the one requested.

Source

Thrown at packages/serverless-client/src/renderer-transport.ts:110

	expectedAttempt,
}: {
	value: unknown;
	expectedChunk: number;
	expectedAttempt: number;
}): S3RendererStatus => {
	if (typeof value !== 'object' || value === null) {
		throw new Error('Renderer S3 status must be an object');
	}

	const status = value as Record<string, unknown>;
	if (status.schema !== 1) {
		throw new Error(
			`Unsupported renderer S3 status schema: ${String(status.schema)}`,
		);
	}

	if (status.chunk !== expectedChunk || status.attempt !== expectedAttempt) {
		throw new Error(
			`Renderer S3 status identifies chunk ${String(status.chunk)}, attempt ${String(status.attempt)}; expected chunk ${expectedChunk}, attempt ${expectedAttempt}`,
		);
	}

	if (
		typeof status.lambdaInvoked !== 'boolean' ||
		!isNumber(status.renderedFrames) ||
		!isNumber(status.encodedFrames) ||
		!isNumber(status.startedAt)
	) {
		throw new Error('Renderer S3 status has invalid progress fields');
	}

	if (status.state === 'running') {
		return status as S3RendererStatus;
	}

	if (status.state === 'completed') {

View on GitHub (pinned to 10db9de073)

Solutions

Always retry with a fresh renderId - never reuse one while a previous attempt may still be writing.
Ensure only one orchestrator drives a given renderId at a time (single-writer queue or locking).
Align @remotion/* versions and redeploy the renderers, then retry.
If it happens with matched, single-writer setups, capture both the object key and body and report it as a Remotion bug.

Defensive patterns

Strategy: retry

Validate before calling

// Single-writer guard: never run two orchestrators against one renderId
const renderId = `${Date.now()}-${crypto.randomUUID()}`; // fresh per attempt
if (await renderFolderExists(bucketName, renderId)) {
  throw new Error('renderId collision - generate a new one');
}

Try / catch

try {
  await renderMediaOnCloudRun({...input, renderId});
} catch (err) {
  if (/identifies chunk .* attempt .*; expected chunk/.test(err.message)) {
    // stale/foreign status at this key - retry once with a brand-new renderId
    await renderMediaOnCloudRun({...input, renderId: makeRenderId()});
  } else {
    throw err;
  }
}

Prevention

Always retry with a fresh renderId; never reuse one while a previous attempt may still be writing status files.
Ensure exactly one orchestrator process drives a given renderId (queue or lock).
Keep renderer and orchestrator Remotion versions identical to avoid protocol drift.

When it happens

Trigger: A retried render attempt writing its status to the wrong attempt key; two renderer instances writing to the same renderId concurrently; version skew or bucket-path reuse across simultaneous renders producing inconsistent key/body pairs.

Common situations: Retry orchestration reusing the same renderId; concurrent renders accidentally sharing a bucket prefix; a partially upgraded deployment mixing old and new writers.

Related errors

AI-assisted analysis of remotion-dev/remotion@10db9de073 (2026-08-22). Data as JSON: /api/errors/a20acad34f5e5e77. Report an issue: GitHub.