Repository navigation
feat(flare-proxy): env-var model routing (MODEL/MODEL_OPUS/SONNET/HAIKU) - #264
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughProvider configuration now loads model routes from environment variables, resolves keyword-specific or fallback routes, and applies each route’s upstream model to forwarded OpenAI requests. ChangesModel routing and proxy forwarding
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Client
participant proxy_request
participant ProviderConfig
participant Upstream
Client->>proxy_request: Send Anthropic model request
proxy_request->>ProviderConfig: resolve_model(model)
ProviderConfig-->>proxy_request: Return ModelRoute
proxy_request->>Upstream: Send translated request with route.upstream_model
Upstream-->>proxy_request: Return response
Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@crates/flare-proxy/src/providers.rs`:
- Around line 72-141: The provider parsing in ProviderConfig::from_env()
silently skips unsupported prefixes while retaining routes that reference them.
Validate each parsed provider prefix against the supported match arms before
building providers, and fail startup or emit a warning with clear context for
unsupported values; ensure unsupported provider_ids do not remain as apparently
valid routes that later fail with unknown provider.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 635cdec3-843d-42b5-a079-15f21e08e448
📒 Files selected for processing (3)
crates/flare-proxy/src/forward.rscrates/flare-proxy/src/lib.rscrates/flare-proxy/src/providers.rs
An unrecognized provider prefix in MODEL/MODEL_OPUS/MODEL_SONNET/MODEL_HAIKU was silently dropped from the providers list (the `_ => continue` arm) while the ModelRoute referencing it survived unchanged -- so a typo'd provider looked like a successful startup and only surfaced as an opaque "unknown provider" error once a request actually routed to it. Validate all parsed provider prefixes up front and fall back to default_free() with a clear stderr message when one is unsupported.
Summary
ProviderConfig::from_env()reads MODEL/MODEL_OPUS/MODEL_SONNET/MODEL_HAIKU (formatprovider_type/model_name), replacing the hardcoded 3-routedefault_free()defaultresolve_model()substring-matches opus/sonnet/haiku against env overrides, falls back to the default MODEL route, then exact match — fixes the fix(mcp): return text asset content as UTF-8, not base64 #211 upstream_model bug (route.upstream_model is now substituted into the translated request)route_for()(superseded byresolve_model(), zero remaining callers)parse_model_stringandresolve_model's substring-match + fallback behavior (previously untested)Part of #212 (flare-proxy feature parity epic), Phase 1 item #1.
Test plan
cargo build --workspace --all-featurescargo fmt --all -- --checkcargo test -p flare-proxy(20/20 pass)Summary by CodeRabbit
MODEL,MODEL_OPUS,MODEL_SONNET, andMODEL_HAIKU.