Repository navigation
perf(cli): lambda deploy warms the video function so the first render does not wait for its image - #6376
Conversation
… does not wait for its image A freshly deployed container-image function loads its image on first use, which added about 12 s to the first render's plan on some deploys. Deploy now invokes the function's warm action once after the stack is up (default on, --no-warm skips it). A failed warm-up prints a warning and the deploy still succeeds.
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Automations to automatically generate PRs for you. |
![heygengenesis[bot]](https://avatars.githubusercontent.com/in/2913576?s=60&v=4){kind=small}
There was a problem hiding this comment.
Verdict: REQUEST CHANGES · 1 blocker · 0 important · 1 nit · head f98ae01f
- blocker: required check Skills: manifest in sync fails —
skills/hyperframes-cli/references/lambda.mdchanged without regeneratingskills-manifest.json(bun packages/cli/scripts/gen-skills-manifest.ts, then commit).
The warm path itself looks right: the handler's Action: "warm" branch exists, every failure (missing CLI, timeout, non-zero exit, FunctionError) is caught and kept non-fatal, and the x86_64 skip is covered.
Scope / CI
Read the full diff plus handler.ts warm branch, sam.ts and template.yaml video-function outputs. Didn't run tests locally (no bun in the sandbox), so I relied on CI. Fallow audit (not required) also fails: runDeploy goes over the complexity gate (24/20), and touching sam.ts surfaces the existing samDeploy/samDelete clone. Pulling the warm block into a helper would clear the first one.
…kills manifest Regenerates skills-manifest.json for the lambda reference change, keeps runDeploy under the complexity gate by pulling the warm step into a helper, and leaves sam.ts untouched.
…r the profile sets A profile configured for text or yaml output made the reply unparseable, which printed a spurious warm-up warning.
There was a problem hiding this comment.
Verdict: APPROVE — 2 resolved, 0 open, 0 new · f98ae01f → 729519de
The manifest is back in sync and the invoke now passes --output json. Fallow audit still fails, though it isn't required: runDeploy is at 23/20, so the helper extraction didn't clear it, despite the update. Tests on windows-latest: engine-cli hung in studioServer.test.ts's history test, which this PR doesn't touch, and passed on rerun.
… out of runDeploy
There was a problem hiding this comment.
Verdict: APPROVE — 0 resolved, 0 open, 0 new · 729519de → 76d9803f
This is a pure extraction: the warm guard moved into warmVideoFunction, and the concurrency notice is unchanged. All CI passes on this head, including Fallow audit and the Windows tests.
Problem
A newly deployed container-image function loads its image on first use. On a share of fresh deploys the first render's plan took 13 to 17 s instead of 2 to 3 s, and no later render did. The first render after an upgrade is the one people judge the stack on.
Change
hyperframes lambda deployinvokes the video function's existingwarmaction once, after the stack is up and the state file is written, and prints one line (Warming up the video function). On by default;--no-warmskips it. A failed warm-up prints a warning and the deploy still succeeds. Nothing to warm on--video-arch x86_64(no image function).Evidence
warm: falseand--video-arch x86_64do not call it. The first two fail with the call removed or the failure made fatal.