feat: classify standalone deploys#5903
feat: classify standalone deploys#5903kaposke wants to merge 1 commit intogui/NAN-5277/feat-consolidate-function-sourcefrom
standalone deploys#5903Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6a971a5994
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| }); | ||
| if (existingSyncConfig && existingSyncConfig.source === 'catalog') { | ||
|
|
||
| if (existingSyncConfig && existingSyncConfig.source !== 'standalone') { |
There was a problem hiding this comment.
Allow overwriting legacy repo-sourced standalone functions
This guard now blocks updates for any existing function whose source is not 'standalone', but the source backfill migration explicitly set all non-catalog historical configs to 'repo' (packages/database/lib/migrations/20260417120000_sync_config_code_source.cjs, lines 21-23). As a result, remote functions deployed before this classification change will now fail redeploys through /functions/deploy with invalid_request, which is a production regression for existing users unless those rows are migrated or treated as legacy standalone.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
We don't care about them
| /** @deprecated Use CLIDeployFlowConfig.models_json_schema */ | ||
| jsonSchema?: JSONSchema7 | undefined; | ||
| sdkVersion?: string | undefined; | ||
| source?: FunctionSource | undefined; |
There was a problem hiding this comment.
Narrow PostDeploy source type to accepted values
PostDeploy['Body'].source is typed as FunctionSource, which includes 'catalog', but runtime validation only accepts 'standalone' | 'repo' (packages/server/lib/controllers/sync/deploy/validation.ts, line 162). This creates an API contract mismatch where typed callers can send a value that compiles but is guaranteed to be rejected with invalid_body, making the SDK/type surface misleading and harder to integrate correctly.
Useful? React with 👍 / 👎.
| }); | ||
| if (existingSyncConfig && existingSyncConfig.source === 'catalog') { | ||
|
|
||
| if (existingSyncConfig && existingSyncConfig.source !== 'standalone') { |
There was a problem hiding this comment.
Did we land on whether we should/shouldn't allow overwriting templates? Honestly I don't have any strong arguments in either way from an eng PoV, it seems like it's purely a product decision.
Assuming the "standalone" term I made up is accepted, classify functions deployed from the
/remote-function/deployendpoint as "standalone". Done by adding an optionalsourceproperty topostDeploy's body, and making so the CLI reads an optionalNANGO_DEPLOY_SOURCEenv var to send it asstandalone. The sandbox is injected with that flag.