Skip to content

fix: v2 to v1 downgrade failing with CPU error - #10889

Open
IzaakGough wants to merge 7 commits into
mainfrom
@invertase/fix-issue-5461
Open

fix: v2 to v1 downgrade failing with CPU error#10889
IzaakGough wants to merge 7 commits into
mainfrom
@invertase/fix-issue-5461

Conversation

@IzaakGough

@IzaakGough IzaakGough commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Fixes #5461

Redeploying an existing v2 function as v1 failed with a confusing "Cannot set CPU on ... because they are GCF gen 1" error. inferDetailsFromExisting was copying v2-only infrastructure fields (cpu, availableMemoryMb, timeoutSeconds) from the deployed function onto the new v1 endpoint, which then tripped CPU validation and hid the real error.

These fields are now only inherited when the platform is unchanged, so a v2 to v1 change surfaces the accurate "cannot be downgraded" error instead.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates inferDetailsFromExisting in src/deploy/functions/prepare.ts to only inherit infrastructure fields (availableMemoryMb, cpu, and timeoutSeconds) when the platform is unchanged. This prevents validation errors (such as setting CPU on GCF gen 1) when downgrading from gcfv2 to gcfv1, allowing the correct downgrade error to be raised. Unit tests have been added in src/deploy/functions/prepare.spec.ts to cover these scenarios. There are no review comments, and the changes look solid.

@IzaakGough
IzaakGough marked this pull request as ready for review August 6, 2026 10:36
Memory and timeout are valid on both generations, and the platform-equality
guard also skipped them for gcfv2 vs run, which is a legal update. Gate only
cpu, and reject a gcfv2-to-gcfv1 downgrade in validation so the error appears
before the source is uploaded rather than in the release plan.
Skipping cpu inheritance for gcfv1 removed the only thing that stopped a
deploy from trying to update an existing `run` endpoint into a gcfv1
function, which then failed with an opaque API error mid-deploy. Share one
predicate between validation and the release planner so the two checks
cannot drift, and cover both platforms.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Downgrading v2 function to v1 function fails in unexpected way

2 participants