[miguel-heygen]

Follow-up to #5772 from its review: three gaps in the upgrade path that the main render path already handled.

What changes for users

• lambda render-batch and lambda sites create refuse a too-old stack before uploading anything. render-batch uploaded the site once for the whole batch and only then reached the per-render STACK_TOO_OLD check, so an old stack received the upload first. sites create never checked. Both now call the check before deploySite, as lambda render already does.
• An expired site file is re-uploaded only from a matching local copy. lambda render --site-id always passes the project directory. When a file under cas/sha256/ had expired and the local copy was gone or edited, the user saw a raw upload error (a missing file, or S3 rejecting the checksum) instead of SITE_FILES_MISSING. Now a file is re-uploaded only when its local copy hashes to the sha256 the site lists; anything else counts as missing and the render stops with SITE_FILES_MISSING before starting.
• The deploy guide says where the CLI keeps a stack's state (.hyperframes/lambda-stack-<stack-name>.json in the current directory) and that the other lambda commands read it from there.

How

• assertStackReadsSites (the check renderToLambda already ran) is exported from @hyperframes/aws-lambda/sdk and takes { stateMachineArn, region?, sfn? }. render-batch calls it unless --dry-run; sites create calls it first.
• ensureSiteStored hashes the local copy before re-storing it.

Tests

• packages/cli/src/commands/lambda/stackCheck.test.ts (new): with a too-old stack, render-batch and sites create reject with STACK_TOO_OLD and never call deploySite. Both fail on the old order.
• renderToLambda.test.ts: an edited and then a deleted local copy each give SITE_FILES_MISSING with no upload and no execution. Fails without the hash check.
• Run on Linux on the code before the rebase onto main (identical diff, clean cherry-pick): aws-lambda and cli typecheck pass; renderToLambda.test.ts 18/18; stackCheck.test.ts + render-batch.test.ts 16/16; each new test red with its fix reverted; 3 consecutive green runs; verify:packed-manifests passes.

Not done

• No live AWS run for this change. Each fix is a call-order or local-hash change covered by the tests above.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
hyperframes	🟢 Ready	View Preview	Oct 19, 2026, 8:29 PM

💡 Tip: Enable Automations to automatically generate PRs for you.

[somanshreddy]

Reviewed at b716d1d7. No blocker, so I'm approving. One small doc gap is noted below.

What I checked

• Stack check runs first.
  • render-batch now calls assertStackReadsSites before both deploySite and siteHandleFromId, so it also runs with --site-id, and it's skipped only for --dry-run.
  • sites create calls it first.
  • Both pass stack.region from the saved stack state.
  • renderToLambda still runs its own check per render, using the caller's sfn.
• Expired-file re-upload only from a matching copy. In ensureSiteStored, an expired cas/sha256/ file is re-uploaded only when the local copy exists and its sha256 matches the site's listing. An edited or deleted copy now counts as missing, so the render stops with SITE_FILES_MISSING before any upload or execution. This closes my should-fix (1) on #5772. Hashing only happens on the expired path, so it doesn't add work to normal renders.
• Tests:
  • aws-lambda renderToLambda.test.ts passes 18 of 18 (bun test), and tsc is clean.
  • CLI stackCheck.test.ts + render-batch.test.ts pass 16 of 16.
  • Mutation check: dropping the hasContent check fails "refuses when the project dir's copy differs or is gone, uploading nothing".
• CI had 24 pass, 16 pending and 0 failing.

Should-fix (docs): sites create now needs states:DescribeStateMachine
docs/deploy/aws-lambda.mdx:179 lists that permission only for code that calls renderToLambda. A CI role that only uploads sites (S3 read/write) would now fail sites create with AccessDenied from Step Functions. Adding "and lambda sites create / render-batch" to that line covers it.

Nit: if a site path resolves to a directory locally, existsSync passes and sha256File throws EISDIR, which is a raw error instead of SITE_FILES_MISSING. That's unlikely, since site paths come from file listings. statSync(...).isFile() would close it.

No live AWS run, same as the PR.

— Somu