remotion-dev/remotion · error · Error
Unknown renderer S3 status state: ${String(status.state)}
Error message
Unknown renderer S3 status state: ${String(status.state)} What it means
After validating the base fields, parseS3RendererStatus() accepts only state values 'running', 'completed', and 'failed'. Any other value falls through to this error - by design, so a status written by a newer renderer that introduced a new state cannot be misinterpreted by an older orchestrator.
Source
Thrown at packages/serverless-client/src/renderer-transport.ts:178
}
return status as S3RendererStatus;
}
if (status.state === 'failed') {
if (
!isNumber(status.failedAt) ||
typeof status.shouldRetry !== 'boolean' ||
typeof status.errorInfo !== 'object' ||
status.errorInfo === null
) {
throw new Error('Renderer S3 failed status is invalid');
}
return status as S3RendererStatus;
}
throw new Error(`Unknown renderer S3 status state: ${String(status.state)}`);
};
View on GitHub (pinned to 10db9de073)
Solutions
- Align every @remotion/* package to one exact version and redeploy the renderer functions/image, then retry.
- Run npx remotion versions to find mismatched packages across the project.
- Use a fresh renderId after redeploying so no old status files linger.
- If all versions match exactly and it still occurs, report it as a Remotion bug with the status.json body.
Defensive patterns
Strategy: validation
Validate before calling
# CI gate: all @remotion/* packages must be the same version before deploying renderers npm ls @remotion/serverless @remotion/serverless-client @remotion/cli --depth=0 npx remotion versions
Try / catch
try {
await renderMediaOnCloudRun(input);
} catch (err) {
if (err.message.startsWith('Unknown renderer S3 status state')) {
throw new Error('Renderer wrote a status state this orchestrator does not know - redeploy with matching versions and retry');
}
throw err;
} Prevention
- Pin exact matching versions for every @remotion/* package and redeploy renderer images/functions together with the CLI.
- Never let a shared bucket be written by renderers of different Remotion generations.
- Run npx remotion versions in CI to catch skew before it surfaces as unknown-state errors.
When it happens
Trigger: Version skew: a newer renderer wrote a state value this parser does not know; or a corrupted/foreign file sits at the status key with an arbitrary state field.
Common situations: CLI upgraded but the Cloud Run image / Lambda functions not redeployed (or the reverse); a shared bucket written to by multiple Remotion generations.
Related errors
- Unsupported renderer S3 status schema: ${String(status.schem
- Renderer S3 status must be an object
- Renderer S3 status identifies chunk ${String(status.chunk)},
- Renderer S3 status has invalid progress fields
- Renderer S3 completed status is invalid
AI-assisted analysis of remotion-dev/remotion@10db9de073 (2026-08-22).
Data as JSON: /api/errors/8c6891757bdfc3cb.
Report an issue: GitHub.