fix(db): migrate failover_db queries to use model_name instead of dropped model_id column#1023
fix(db): migrate failover_db queries to use model_name instead of dropped model_id column#1023
Conversation
…pped model_id column Updates all failover database queries to use the correct column references after migrations 20260131000002 (dropped model_id) and 20260121000003 (moved pricing to model_pricing table). Changes: - get_providers_for_model(): Use model_name for filtering, join with model_pricing table for pricing data - get_provider_model_id(): Use model_name for filtering - check_model_available_on_provider(): Use model_name for filtering Handles PostgREST list response for model_pricing relationship. Fixes Sentry issue GATEWAYZ-BACKEND-86 - PostgreSQL error 42703: "column models.model_id does not exist" 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| try: | ||
| supabase = get_supabase_client() | ||
|
|
||
| # Note: model_id column was dropped from models table - now using model_name | ||
| response = supabase.table("models").select( | ||
| "provider_model_id" | ||
| ).eq( | ||
| "model_id", canonical_model_id | ||
| "model_name", canonical_model_id | ||
| ).eq( | ||
| "providers.slug", provider_slug | ||
| ).single().execute() |
There was a problem hiding this comment.
Bug: The get_provider_model_id and check_model_available_on_provider functions filter on providers table columns without including providers!inner() in the select() clause, which will cause the queries to fail.
Severity: CRITICAL
Suggested Fix
Update the queries in get_provider_model_id and check_model_available_on_provider to include the providers!inner() relationship in the select() clause before applying filters on the providers table. For example, change .select("provider_model_id") to .select("provider_model_id, providers!inner(slug)").
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/db/failover_db.py#L207-L217
Potential issue: The functions `get_provider_model_id` and
`check_model_available_on_provider` in `src/db/failover_db.py` build PostgREST queries
that filter on columns from the related `providers` table, such as `providers.slug` and
`providers.is_active`. However, the `select()` clause in these queries omits the
required `providers!inner()` relationship. This will cause PostgREST to fail when trying
to resolve the filter columns, likely resulting in an error or an empty result set. This
will break the critical failover logic that relies on these database lookups to
determine model availability on different providers.
Did we get this right? 👍 / 👎 to inform future reviews.
1 participant
Summary
Fixes failover database queries that still reference the dropped
model_idcolumn and removed pricing columns from themodelstable.This PR addresses the outstanding
failover_db.pyfixes from PR #1018 which were not merged when that PR was closed.Sentry Issue Fixed
Root Cause
Migrations removed the
model_idcolumn and pricing columns from themodelstable:model_idcolumn (usemodel_nameinstead)model_pricingtableHowever,
src/db/failover_db.pystill contained queries using these dropped columns.Changes Made
Modified Files (1)
src/db/failover_db.py
Functions Updated:
get_providers_for_model():.eq("model_id", model_id)→.eq("model_name", model_id)model_pricingrelationship JOIN for pricing datamodel_pricingget_provider_model_id():.eq("model_id", ...)→.eq("model_name", ...)check_model_available_on_provider():.eq("model_id", ...)→.eq("model_name", ...)New Test Files (1)
tests/db/test_failover_db_model_name_fix.py
model_pricingrelationshipTest plan
🤖 Generated with Claude Code
Greptile Overview
Greptile Summary
This PR completes the migration from the dropped
models.model_idcolumn tomodel_namefor failover database queries, fixing a PostgreSQL error (GATEWAYZ-BACKEND-86) that was occurring in production.Key Changes:
get_providers_for_model()to filter bymodel_nameinstead ofmodel_idand retrieve pricing from themodel_pricingrelationship tableget_provider_model_id()to query usingmodel_namecheck_model_available_on_provider()to filter bymodel_namemodel_pricingrelationshipContext:
This follows migration 20260131000002 which dropped the redundant
model_idcolumn, and migration 20260121000003 which moved pricing data to a separatemodel_pricingtable. PR #1021 fixed similar issues inpricing.pyandpricing_lookup.py, while this PR addresses the remaining references infailover_db.py.Confidence Score: 5/5
model_idtomodel_namecolumn, properly handle themodel_pricingrelationship JOIN, include defensive coding for missing data, and have comprehensive test coverageImportant Files Changed
model_idcolumn tomodel_namecolumn and addedmodel_pricingrelationship JOIN for pricing datamodel_namecolumn usage andmodel_pricingrelationship handlingSequence Diagram
sequenceDiagram participant Client as Failover Service participant DB as failover_db.py participant Supabase as Supabase/PostgREST participant Models as models table participant Pricing as model_pricing table participant Providers as providers table Note over Client,Providers: Failover Query Flow (After Migration) Client->>DB: get_providers_for_model("gpt-4") DB->>Supabase: SELECT with JOINs Note right of DB: Query uses model_name<br/>(not dropped model_id) Supabase->>Models: .eq("model_name", "gpt-4") Models-->>Supabase: Returns model rows Supabase->>Pricing: JOIN model_pricing (relationship) Pricing-->>Supabase: Returns pricing data Note right of Pricing: price_per_input_token<br/>price_per_output_token<br/>price_per_image_token<br/>price_per_request Supabase->>Providers: JOIN providers!inner Providers-->>Supabase: Returns provider metadata Supabase-->>DB: Combined result set DB->>DB: Extract pricing from model_pricing Note right of DB: Handle list format<br/>from PostgREST DB->>DB: Build provider dicts Note right of DB: Map model_name → model_id<br/>Extract pricing fields DB->>DB: Sort by health, speed, cost DB-->>Client: Sorted provider list Note left of Client: Ready for failover routing