feat(gui): complete local provider logo coverage#411
feat(gui): complete local provider logo coverage#411HaydernCenterpoint wants to merge 4 commits into
Conversation
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
Warning Review limit reached
Next review available in: 54 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (54)
📒 Files selected for processing (29)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d01b164940
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const allowsModelsEnvelope = (prov.adapter === "google" && (prov.googleMode ?? "ai-studio") === "ai-studio") | ||
| || new URL(url).pathname.replace(/\/+$/, "").endsWith("/api/tags"); | ||
| const items = parseProviderModelsApiItems(json, allowsModelsEnvelope); |
There was a problem hiding this comment.
When this enables the Google AI Studio {models} envelope, every returned row is normalized into the Codex-visible chat catalog. The AI Studio models list also includes non-generative resources such as embedding-only models (e.g. rows whose supported methods are only embedContent), so those IDs can appear in the model picker and then fail when Codex sends chat/generate requests. Filter Google rows to generation-capable methods (generateContent/streaming) before accepting them as provider chat models.
Useful? React with 👍 / 👎.
| const invalidateDiscoveryRequest = () => { | ||
| discoveryRequestRef.current += 1; | ||
| discoveryAbortRef.current?.abort(); | ||
| discoveryAbortRef.current = null; | ||
| setDiscoveryBusy(false); | ||
| }; |
There was a problem hiding this comment.
After a successful discovery, changing the endpoint, base URL, adapter, API key, or private-network toggle calls this invalidation helper, but it only aborts in-flight requests and leaves discoveredModels, selectedModels, discoverySource, and any auto-filled default model intact. In that scenario the user can save a provider for a different endpoint while the old model list/default model is still displayed and may be submitted as the allowlist, causing the new provider to start with invalid or hidden models. Clear the discovered model state whenever the request is invalidated by form changes.
Useful? React with 👍 / 👎.
| const templateUrl = new URL(entry.baseUrl.replace(/\{[^}]+\}/g, marker)); | ||
| const candidateUrl = new URL(suppliedBaseUrl); | ||
| const escapedPath = templateUrl.pathname.replace(/[.*+?^${}()|[\]\\]/g, "\\$&"); | ||
| const pathPattern = new RegExp(`^${escapedPath.replaceAll(marker, "[A-Za-z0-9_-]+")}/?$`); | ||
| matchesResolvedTemplate = candidateUrl.origin === templateUrl.origin |
There was a problem hiding this comment.
For presets whose placeholder is in the host, such as Azure OpenAI’s https://{resource}.openai.azure.com/openai, replacing the placeholder with the marker makes templateUrl.origin a literal marker host, so a valid user-resolved resource host can never equal it and discovery is rejected as “baseUrl does not match the trusted preset.” The template check needs to pattern-match placeholder host labels as well as placeholder path segments before rejecting resolved preset URLs.
Useful? React with 👍 / 👎.
| const provider = { | ||
| ...providerConfigSeed(entry), | ||
| ...(suppliedBaseUrl ? { baseUrl: suppliedBaseUrl } : {}), | ||
| ...(supplied.apiKey ? { apiKey: supplied.apiKey } : {}), | ||
| ...(supplied.defaultModel ? { defaultModel: supplied.defaultModel } : {}), | ||
| ...(supplied.allowPrivateNetwork === true ? { allowPrivateNetwork: true } : {}), | ||
| ...(supplied.project ? { project: supplied.project } : {}), | ||
| ...(supplied.location ? { location: supplied.location } : {}), |
There was a problem hiding this comment.
When a user selects an OAuth preset that supports API-key override (notably xAI) and clicks “Use an API key instead,” the browser sends authMode: "key" and the typed key, but this rebuilt provider starts from the registry seed and only copies the key/default/base URL, dropping the supplied auth mode. resolveModelsAuthToken therefore treats discovery as OAuth, ignores the typed key, and live discovery falls back or fails even though the saved provider would route with key auth. Preserve the supplied key auth mode when the registry allows key override.
Useful? React with 👍 / 👎.
| baseUrlChoices: [ | ||
| { id: "china-mainland", label: "China mainland", baseUrl: "https://api.siliconflow.cn/v1" }, | ||
| { id: "international", label: "International", baseUrl: "https://api.siliconflow.com/v1" }, | ||
| ], |
There was a problem hiding this comment.
These new SiliconFlow endpoint choices can be selected in the GUI and are accepted by the discovery endpoint, but the router only honors a saved non-template base URL when the registry entry has allowBaseUrlOverride set. Because this entry lacks that flag, a provider saved with the International endpoint is silently rewritten back to https://api.siliconflow.cn/v1 when requests are routed, sending traffic to the wrong regional host. Add allowBaseUrlOverride: true or otherwise teach routing to honor these official choices.
Useful? React with 👍 / 👎.
Summary
Dependencies
feat/provider-model-loaderat60046f85a70e0cc4,c42716de)Validation
bun test tests/provider-workspace-data.test.tsbun run typecheckbun run lint:guibun run build:gui