refactor(providers): canonicalize model-router calls - #1165
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan includes up to 4 reviews per rolling hour; 0 remain after this review. 📝 WalkthroughWalkthroughProvider handlers now use shared fallback constants. Provider fetchers and webview routing now use shared ChangesProvider constant centralization
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to This refactor preserves existing provider values while standardizing model-router calls, and the reported checks pass; no actionable merge-blocking risk remains after normal review. Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
src/api/providers/__tests__/poe.spec.tsESLint skipped: missing config or dependency (missing-dependency). The ESLint configuration references a package that is not available in the sandbox. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
ac0b8f2 to
59c2359
Compare
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
|
|
||
| // flushModels should NOT have been called for litellm | ||
| const litellmFlushCalls = flushModelsMock.mock.calls.filter((c: any[]) => c[0] === "litellm") | ||
| const litellmFlushCalls = flushModelsMock.mock.calls.filter((c: any[]) => c[0] === providerIdentifiers.litellm) |
There was a problem hiding this comment.
c[0] is an options object — comparing it to a string with === is always false, so litellmFlushCalls is always [] and this assertion cannot fail. The getModels filter two lines down already uses the correct pattern.
| const litellmFlushCalls = flushModelsMock.mock.calls.filter((c: any[]) => c[0] === providerIdentifiers.litellm) | |
| const litellmFlushCalls = flushModelsMock.mock.calls.filter((c: any[]) => c[0]?.provider === providerIdentifiers.litellm) |
| try { | ||
| const [models, endpoints] = await Promise.all([ | ||
| getModels({ provider: "openrouter" }), | ||
| getModels({ provider: providerIdentifiers.openrouter }), |
There was a problem hiding this comment.
This PR canonicalized the getModels / getModelEndpoints calls to use providerIdentifiers.openrouter. Should the ApiProviderError calls in handleStreamingError, createMessage, and completePrompt also use providerIdentifiers.openrouter instead of this.providerName ("OpenRouter") for consistency in telemetry grouping? poe.ts was migrated in the same PR.
| }) | ||
|
|
||
| if (!providerFilter || providerFilter === "kimi-code") { | ||
| if (!providerFilter || providerFilter === providerIdentifiers.kimiCode) { |
There was a problem hiding this comment.
Does the routerModels spec have coverage for this branch? I do not see tests for providerFilter === providerIdentifiers.kimiCode, or for the api-key vs. OAuth dispatch and the null-token exclusion inside it.
| const result = handler.getModel() | ||
|
|
||
| expect(getModelsFromCache).toHaveBeenCalledWith({ | ||
| provider: providerIdentifiers.poe, |
There was a problem hiding this comment.
Since both the production code and this assertion import providerIdentifiers.poe, a regression where production reverts to the literal "poe" goes undetected here. Would using the string literal "poe" in the expectation be more mutation-resistant? (The constant's string value is already pinned in provider-identifiers.test.ts.)
Summary
providerIdentifiersregistry for model-router provider options and cache callsValidation
npx vitest run api/providers/__tests__/poe.spec.ts api/providers/fetchers/__tests__/modelEndpointCache.spec.ts core/webview/__tests__/webviewMessageHandler.routerModels.spec.ts— 28 tests passedpnpm run check-typesinsrc— passedRelated to #944 (remaining-work item 4).
Summary by CodeRabbit
Bug Fixes
Tests