@remotion/lambda-client: Do not dump payload into oversize error

[DeryFerd]

Summary

callFunctionAsyncImplementation() refuses payloads over 256 KB before anything is sent to AWS, throwing a local error that reports the measured size. Until now, the message also appended the entire serialized payload after the byte count. This PR removes that echo and leaves the rest of the message untouched.

The payload being checked is not just data. It carries webhook.secret, licenseKey, and customCredentials.secretAccessKey for custom S3 output buckets, on top of whatever the user stored in inputProps, which can be anything at all. The error text ends with "please report this to the Remotion team", so when someone actually hits this guard the natural next step is to copy the message into a GitHub issue, and that copy would contain their webhook signing secret and AWS credentials verbatim. Error trackers capture Error.message the same way. The throw happens before InvokeCommand, so nothing of this reaches CloudWatch; the exposure is the path from the user's console or CI log into a public bug report.

This is the follow-up that was offered in #12114 when the measurement was switched to Buffer.byteLength. That change kept the dump in place to stay a one-line diff and noted that redacting fields like webhook.secret or licenseKey could be done separately. The two changes pair naturally: #12114 made the number in the message honest, and this one makes the message safe to paste. The guard condition, the error type, and the printed byte count are all unchanged; a payload that threw before still throws, with the same wording minus the payload itself.

I removed the whole echo rather than redacting known fields. inputProps is user-defined, so any field-by-field scheme is an allowlist that silently misses whatever the next user puts there. Dropping the echo is complete by construction, and what remains (size, limit, ask to report) is what the caller needs anyway. The caller still has the payload in scope if they want to inspect it themselves.

Validation

I verified this with a throwaway test in the style of the existing call-lambda-sync.test.ts (mocked ../aws-clients, dynamic import of the implementation) and removed it again before committing to keep the PR source-only; happy to add a permanent regression test if you would like one.

• The fixture was a payload holding 200,000 CJK characters plus a webhook.secret and a licenseKey, serializing to 600,109 UTF-8 bytes, comfortably over the limit. Before the change, the assertion that the message must not contain the secret failed, which is the leak: the thrown message ended with the full payload, secret included. After the change, the message is exactly Payload is too big: 600109 bytes. Maximum size is 256 KB. This should not happen, please report this to the Remotion team., and the mocked Lambda client is never called.
• bunx eslint src in packages/lambda-client: 0 errors. The 2 warnings are pre-existing in untouched files (aws-clients.ts unused disable directive, constants.ts TODO comment) and are identical before and after.
• bunx tsgo -d: 121 errors with the change and 121 without it, compared by stashing the edit. The only entry in call-lambda-async.ts is the pre-existing TS2307: Cannot find module '@remotion/serverless-client' from unbuilt workspace types in this checkout, present on the baseline too.
• bun test src in packages/lambda-client: 9 pass / 7 fail / 7 errors before and after, same set. The failures are missing-module errors for workspace packages that are not built in this environment, unrelated to this file.
• Documentation: no page under docs/lambda/ quotes this client-side error text, so there is nothing to update.

Tradeoffs

What you lose is seeing which field pushed the payload over 256 KB from the error message alone. In practice the person hitting this guard constructed the payload a few lines above the call, and the byte count already says how far over the limit it is; anyone debugging further can log the payload themselves, deliberately. I considered keeping a truncated dump (first few hundred characters, say), but truncation still leaks whatever field happens to sit at the front, so it buys little. If you would rather keep some form of payload preview or take the redaction route instead, that is easy to swap in on top of this.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
bugs	Ready	Preview	Oct 11, 2026 9:49am UTC
remotion	Ready	Preview	Oct 11, 2026 9:49am UTC

[pullfrog]

✅ No new issues found.

Reviewed changes

Security fix in @remotion/lambda-client that stops leaking the serialized Lambda payload into the client-side oversize error message.

• Remove payload echo from oversize error (packages/lambda-client/src/call-lambda-async.ts:25) — the Payload: ${stringifiedPayload} suffix is dropped, leaving Payload is too big: ${byteLength} bytes…. The guard, threshold (> 256 * 1024), error type, and measured byte count are unchanged, so behavior is identical except the message no longer contains webhook.secret, licenseKey, or customCredentials.secretAccessKey.

I grepped the monorepo for consumers of the message text (Payload is too big, Maximum size is, Payload:) and found no tests, docs, or parsers that depend on the removed suffix, so nothing downstream breaks.

  ^{｜ View workflow run ｜ Using deepseek-v4.1-flash ｜ 𝕏}