fix: resolve model config provider via ai_provider_id#26660
Draft
johnstcn wants to merge 5 commits into
Draft
Conversation
The denormalized provider text column on chat_model_configs can mismatch the provider type of the linked ai_providers row. The list endpoint now fetches AI providers and overrides the provider field from ai_providers.type, fixing stale legacy rows. The Models page icon now uses the provider type resolved through providerStates (via ai_provider_id) instead of the raw model.provider text, matching the behavior of the Provider column. Refs: CODAGT-617
The denormalized provider text column on chat_model_configs can mismatch the provider type of the linked ai_providers row. The list endpoint now fetches AI providers and overrides the provider field from ai_providers.type, fixing stale legacy rows. The Models page icon now uses the provider type resolved through providerStates (via ai_provider_id) instead of the raw model.provider text, matching the behavior of the Provider column. Refs: CODAGT-617
Member
Author
Deep Review SummaryRan 3 parallel reviewers (Go Architect, Frontend Reviewer, Test Auditor). Findings addressed in this push:
No findings (Frontend Reviewer): 5 observations confirming fixture correctness, fallback soundness, and assertion reliability. Generated with Coder Agents. |
The GetChatModelConfigs and GetEnabledChatModelConfigs queries now LEFT/INNER JOIN ai_providers and use COALESCE(ap.type::text, cmc.provider) so the provider column reflects the canonical ai_providers.type rather than the stale denormalized text on chat_model_configs. The Models page icon uses the provider type resolved through providerStates (via ai_provider_id) instead of the raw model.provider text. Refs: CODAGT-549
The SQL query already returns COALESCE(ap.type, cmc.provider) as the provider field, so model.provider on the frontend is correct. The providerType prop and providerTypeByModelId map were resolving the same ai_provider_id -> ai_providers.type path server-side, adding duplication. Refs: CODAGT-549
The provider creation form was sending type=anthropic with Bedrock settings, relying on the BackfillBedrockProviderType startup backfill to promote it to type=bedrock. Until the backfill runs (next restart), the provider appears as Anthropic in all UI surfaces that read ai_providers.type directly. Send type=bedrock at creation time so the provider is stored correctly from the start. The backend validation already accepts type=bedrock with Bedrock settings. Refs: CODAGT-549
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
1 participant
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.
The
GetChatModelConfigsandGetEnabledChatModelConfigsqueries now joinai_providersand useCOALESCE(ap.type::text, cmc.provider) AS providerso theprovidercolumn reflects the canonicalai_providers.typerather than the stale denormalized text onchat_model_configs.The provider creation form now sends
type=bedrockat creation time instead oftype=anthropicwith Bedrock settings. Previously, the form relied on theBackfillBedrockProviderTypestartup backfill to promote the provider type, leaving a window where the provider appeared as Anthropic in all UI surfaces until the next server restart.Implementation details
Backend (
coderd/database/queries/chatmodelconfigs.sql): The two list queries useCOALESCE(ap.type::text, cmc.provider) AS providerwith a LEFT/INNER JOIN toai_providers. sqlc still generates[]ChatModelConfigas the return type.Frontend (
site/src/pages/AISettingsPage/ProvidersPage/components/providerFormApiMap.ts):providerFormValuesToCreatenow returnstype: "bedrock"when the form type isbedrock, instead oftype: "anthropic"with Bedrock settings. The backend validation already acceptstype=bedrockwith Bedrock settings and rejects API keys fortype=bedrock.Tests: Updated
providerFormApiMap.test.tsto expecttype: "bedrock"andMockAIProviderBedrockfixture inentities.tstotype: "bedrock".Refs: CODAGT-549