fix: reconstruct build_data when missing on direct-zip deploys#8353
Conversation
ZISI's in-memory FunctionResult returns bootstrapVersion at the top level, but only nests it into buildData when writing the manifest cache. On plain `netlify deploy` and `--skip-functions-cache`, the deploy create payload was sending `build_data: undefined`, causing netlify-server to store an empty bd on every function and route all function uploads through the legacy Lambda env-var path (subject to the 4KB cap). Reconstruct buildData from the top-level fields so bootstrap_version lands on the deploy record correctly. Also lands a unit test asserting build_data.bootstrapVersion is populated for v2 functions on the direct-zip path. RUN-3166 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
❌ Deploy Preview for steady-pastelito-09e39e failed.
|
📝 WalkthroughWalkthrough
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/utils/deploy/hash-fns.ts (1)
157-158: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winRemove comments that only describe the implementation.
These comments explain what the following code does; the fallback is self-explanatory. As per coding guidelines,
**/*.{ts,tsx,js,jsx}: Never write comments on what the code does; make the code clean and self-explanatory instead.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/utils/deploy/hash-fns.ts` around lines 157 - 158, Remove the implementation-detail comment above the direct-zip fallback in the hash-fns flow, leaving the self-explanatory code unchanged.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/utils/deploy/hash-fns.ts`:
- Around line 157-158: Remove the implementation-detail comment above the
direct-zip fallback in the hash-fns flow, leaving the self-explanatory code
unchanged.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 46c337c7-3fc3-4530-8c10-a411f9d338c5
📒 Files selected for processing (2)
src/utils/deploy/hash-fns.tstests/unit/utils/deploy/hash-fns.test.ts
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
netlify/blueprints(manual)
Summary
Plain
netlify deploy(andnetlify deploy --skip-functions-cache) has been silently sendingbuild_data: undefinedfor every function in the deploy create payload. Downstream tooling relies onbuild_data.bootstrapVersionandbuild_data.runtimeAPIVersionto route function uploads correctly.Root cause:
@netlify/zip-it-and-ship-it's in-memoryFunctionResultexposesbootstrapVersionandruntimeAPIVersionat the top level, but only nests them intobuildDatawhen writing the manifest cache. Without a manifest hit,func.buildDataisundefined.This patch restores the reconstruction loop originally proposed in #7099 (closed unmerged) so per-function metadata reaches the deploy record on direct-zip paths.
A companion patch in
@netlify/zip-it-and-ship-it(netlify/build#7139) fixes the shape at source. This CLI change remains useful as a defense against older ZISI versions.Test plan
hash-fns.test.tsassertsfnConfig.build_data.bootstrapVersionis populated for a v2 function on the direct-zip path🤖 Generated with Claude Code