fix(models): copy provider_model_id when merging Vertex API models with static config

[vdimarco]

Summary

Follow-up fix to PR #775. This addresses a bug identified by Sentry's code review after PR #775 was merged.

Issue

When fetching models from the Google Vertex API and merging them with static configuration, the provider_model_id was not being copied from static config. This caused the database sync to fall back to using the canonical model_id instead of the correct provider model ID.

Root Cause

In fetch_models_from_google_vertex(), when the Vertex API successfully returns models, the code merges them with static config for pricing/tags/name/description, but it was missing the provider_model_id field.

Impact

When the Vertex API is available (which is the preferred path), models like gemini-3-flash would have their canonical ID stored instead of the correct provider model ID (gemini-3-flash-preview), causing database lookup failures for:

• Chat completion request saves
• Model health metrics recording

Fix

Added code to copy provider_model_id from static config when merging API models.

Test Plan

• All 13 tests pass in tests/services/test_model_catalog_sync.py
• All 40 tests pass in tests/services/test_google_vertex_client.py
• Verify model sync runs successfully after deployment
• Verify chat completion requests are saved for gemini-3-flash-preview when API is available

Related

• Original PR: fix(models): add provider_model_id support for Google Vertex model sync #775
• Sentry bug report: fix(models): add provider_model_id support for Google Vertex model sync #775 (comment)

🤖 Generated with Claude Code

Greptile Overview

Greptile Summary

Overview

This PR fixes a critical bug where provider_model_id was not being copied from static configuration when merging Vertex API models. This is a follow-up to PR #775, addressing an oversight identified by Sentry's code review.

What Changed

Added 4 lines of code (lines 1676-1679) in fetch_models_from_google_vertex() to copy provider_model_id from static config when merging API-fetched models with static configuration.

Why This Matters

For Gemini 3 models, the canonical model ID (e.g., gemini-3-flash) differs from the provider model ID used in API requests (e.g., gemini-3-flash-preview). Without this fix:

• When Vertex API successfully returns models (the preferred path)
• The merge with static config would copy pricing, tags, name, and description
• But miss provider_model_id, causing it to fall back to canonical ID
• Database lookups for chat completion saves would fail
• Model health metrics would not be recorded correctly

Code Flow

1. Static config (_get_static_model_config) creates models with correct provider_model_id (added in PR fix(models): add provider_model_id support for Google Vertex model sync #775)
2. API fetch (_fetch_models_from_vertex_api) retrieves models from Google
3. Normalization (_normalize_vertex_api_model) converts API response (doesn't set provider_model_id)
4. Merge (lines 1669-1679) - THIS IS WHERE THE FIX IS
   • Copies pricing, tags, name, description from static config
   • NOW ALSO copies provider_model_id if present in static config
5. Database sync uses provider_model_id for lookups

Testing

The existing test suite validates this fix:

• test_model_catalog_sync.py::TestGoogleVertexProviderModelId has comprehensive tests
• Tests verify gemini-3-flash → gemini-3-flash-preview mapping
• All 13 tests in model catalog sync pass
• All 40 tests in Google Vertex client pass

Impact Assessment

✅ Fix is correct and complete

• The conditional check if static.get("provider_model_id"): is appropriate
• Handles missing/None values correctly
• Consistent with how other fields are merged
• No breaking changes

Confidence Score: 5/5

• This PR is safe to merge with no identified risks. It's a focused bug fix that addresses a specific oversight in the model merging logic.
• Perfect score (5/5) because: (1) The fix is minimal and surgical - only 4 lines added to copy provider_model_id during merge, (2) Addresses a real production bug affecting Gemini 3 models where database lookups fail, (3) Implementation is correct with proper conditional checking, (4) Comprehensive test coverage exists and passes, (5) No breaking changes or side effects, (6) Consistent with how other fields are merged in the same code block, (7) Follow-up to PR fix(models): add provider_model_id support for Google Vertex model sync #775 completing the intended fix.
• No files require special attention. The single file changed contains a straightforward bug fix that correctly addresses the issue.

Important Files Changed

File Analysis

Filename	Score	Overview
src/services/google_vertex_client.py	5/5	Added provider_model_id copying when merging Vertex API models with static config. Fix is correct and addresses the bug from PR #775 where Gemini 3 models had incorrect provider_model_id.

Sequence Diagram

sequenceDiagram
    participant Client as Model Sync Service
    participant FMGV as fetch_models_from_google_vertex()
    participant API as Vertex AI API
    participant Static as Static Config
    participant Normalize as _normalize_vertex_api_model()
    participant DB as Database Sync

    Client->>FMGV: Request models
    FMGV->>Static: Get static model config
    Static-->>FMGV: Returns static models with provider_model_id
    
    FMGV->>API: Fetch models from API
    alt API Available
        API-->>FMGV: Returns API models
        
        loop For each API model
            FMGV->>Normalize: Normalize API model
            Normalize-->>FMGV: Normalized model (no provider_model_id)
            
            alt Model exists in static config
                Note over FMGV: Merge static metadata
                FMGV->>FMGV: Copy pricing, tags, name, description
                FMGV->>FMGV: Copy provider_model_id (THIS FIX)
                Note over FMGV: Critical for Gemini 3 models<br/>where canonical ID differs<br/>from provider model ID
            end
        end
        
        FMGV->>FMGV: Add static models not in API
    else API Unavailable
        FMGV->>FMGV: Use static config only
    end
    
    FMGV-->>Client: Returns merged models
    Client->>DB: Sync models with provider_model_id
    Note over DB: Uses provider_model_id for lookups<br/>during chat completion saves

Loading

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[supabase]

This pull request has been ignored for the connected project ynleroehyrmaafkgjgmr because there are no changes detected in supabase/supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

[sentry]

Bug: Model merging fails due to a mismatch between provider model IDs from the API and canonical model IDs used in the static configuration lookup, causing duplicate models.
_{Severity: CRITICAL}

🔍 Detailed Analysis

In fetch_models_from_google_vertex(), models fetched from the Vertex API are normalized using their provider model ID (e.g., "gemini-3-flash-preview"). However, the static model configuration, static_by_id, is indexed by canonical model IDs (e.g., "gemini-3-flash"). The subsequent check if model_id in static_by_id: fails because it attempts to look up the provider ID in the map of canonical IDs. This prevents the merge logic from executing, resulting in API-sourced models having incorrect IDs and missing critical metadata like provider_model_id. This also causes duplicate model entries in the database, as both the incomplete API model and the full static model are added.

💡 Suggested Fix

To fix this, the code needs to correctly map an API model to its corresponding static configuration entry before attempting to merge. This could be done by performing a reverse lookup from the provider model ID to the canonical ID, or by modifying _normalize_vertex_api_model to return the canonical ID and set provider_model_id separately.

🤖 Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: src/services/google_vertex_client.py#L1670

Potential issue: In `fetch_models_from_google_vertex()`, models fetched from the Vertex
API are normalized using their provider model ID (e.g., `"gemini-3-flash-preview"`).
However, the static model configuration, `static_by_id`, is indexed by canonical model
IDs (e.g., `"gemini-3-flash"`). The subsequent check `if model_id in static_by_id:`
fails because it attempts to look up the provider ID in the map of canonical IDs. This
prevents the merge logic from executing, resulting in API-sourced models having
incorrect IDs and missing critical metadata like `provider_model_id`. This also causes
duplicate model entries in the database, as both the incomplete API model and the full
static model are added.

_{Did we get this right? 👍 / 👎 to inform future reviews.
Reference ID: 8438933}