Repository navigation
fix(core): stop sending API key metadata as request body - #53546
Merged
Merged
Conversation
V1 auth.json kept connect-form answers such as the Azure resource name as API key metadata. The legacy import copied them into V2 key metadata, which the model resolver merged into every request body, so migrated Azure keys failed with unknown_parameter: resourceName. Stop projecting key metadata into the request body, import V1 metadata as key configuration, and move already-imported metadata into configuration.
3 of 6 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #53443.
V1
auth.jsonstored connect-form answers (AzureresourceName, CloudflareaccountId/gatewayId, Snowflakeaccount, ...) as API keymetadata. The legacy credential import copied that into V2Credential.Key.metadata, andModelResolvermerged key metadata into every request body. Migrated Azure keys therefore sentresourceNameas a request parameter and failed withunknown_parameter.ModelResolverno longer projects API key metadata into the request body. Provider settings are unchanged, so migrated form answers still reach the provider as before.configurationand falls back tometadata, as the Snowflake plugin already does, so migrated keys keep deployment discovery and${AZURE_RESOURCE_NAME}expansion.No data migration: V1 only read specific metadata keys per provider, and some V1 plugins (e.g. DigitalOcean) kept non-form state in key metadata, so a blanket move into
configurationis not safe.Tests:
bun test test/model-resolver.test.ts test/plugin/provider-azure.test.ts,bun run check.Requested by: @neriousy (Filip via Slack)