fix: forward providerType to chat API for custom provider support#114
Merged
wyuc merged 5 commits intoTHU-MAIC:mainfrom Mar 22, 2026
Merged
fix: forward providerType to chat API for custom provider support#114wyuc merged 5 commits intoTHU-MAIC:mainfrom
wyuc merged 5 commits intoTHU-MAIC:mainfrom
Conversation
wyuc
approved these changes
Mar 22, 2026
Contributor
wyuc
left a comment
wyuc
left a comment
There was a problem hiding this comment.
Replaces the hand-rolled provider resolution in chat route with the shared resolveModel() helper. All three call sites covered, net -13 lines. LGTM.
13 tasks
wyuc
added a commit
that referenced
this pull request
Mar 23, 2026
) PR #114 refactored the chat route to use resolveModel() but replaced the server-resolved API key with the raw client-sent body.apiKey for both the 401 check and the statelessGenerate call. This broke server-configured providers (e.g. OPENAI_API_KEY env var) where the client sends no key. - Add apiKey field to ResolvedModel interface so callers can access the effective key after server-side fallback resolution - Use the resolved apiKey for the 401 guard and pass it to statelessGenerate Fixes #220 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
3 tasks
cosarah
pushed a commit
that referenced
this pull request
Mar 23, 2026
) * fix: use resolved API key in chat route instead of client-sent key (#220) PR #114 refactored the chat route to use resolveModel() but replaced the server-resolved API key with the raw client-sent body.apiKey for both the 401 check and the statelessGenerate call. This broke server-configured providers (e.g. OPENAI_API_KEY env var) where the client sends no key. - Add apiKey field to ResolvedModel interface so callers can access the effective key after server-side fallback resolution - Use the resolved apiKey for the 401 guard and pass it to statelessGenerate Fixes #220 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: allow keyless providers (e.g. local Ollama) to bypass API key check Add requiresApiKey !== false guard so providers that don't need an API key are not rejected by the 401 check. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
ifishcool
pushed a commit
to box3lab/Linksy
that referenced
this pull request
Mar 23, 2026
…HU-MAIC#221) * fix: use resolved API key in chat route instead of client-sent key (THU-MAIC#220) PR THU-MAIC#114 refactored the chat route to use resolveModel() but replaced the server-resolved API key with the raw client-sent body.apiKey for both the 401 check and the statelessGenerate call. This broke server-configured providers (e.g. OPENAI_API_KEY env var) where the client sends no key. - Add apiKey field to ResolvedModel interface so callers can access the effective key after server-side fallback resolution - Use the resolved apiKey for the 401 guard and pass it to statelessGenerate Fixes THU-MAIC#220 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: allow keyless providers (e.g. local Ollama) to bypass API key check Add requiresApiKey !== false guard so providers that don't need an API key are not rejected by the 401 check. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes chat failures for custom LLM providers by forwarding
providerTypeandrequiresApiKeythrough the chat request path and resolving chat models with the sharedresolveModel()helper. Previously,/api/chatused an older provider resolution path and could fail withUnknown provider: custom-... Please provide providerType.for custom providers that worked elsewhere in the app.Related Issues
Fixes #116
Changes
providerTypeandrequiresApiKeytoStatelessChatRequestcomponents/chat/use-chat-sessions.tsin chat, resume, and discussion request flowsapp/api/chat/route.tsto use the sharedresolveModel()helpercustom-*providers without explicit provider metadataType of Change
Verification
Steps to reproduce / test
Unknown provider: custom-... Please provide providerType.What you personally verified
providerTypeandrequiresApiKey/api/chatnow resolves models throughresolveModel(), matching the provider-aware path used by other API routespnpm exec tsc --noEmitpnpm lint app/api/chat/route.ts components/chat/use-chat-sessions.ts lib/types/chat.tspnpm buildGET /api/healthreturned success locallyPOST /api/chatrequest with a custom provider model andproviderTypestreamed a normal SSE response instead of returning the previous 500providerTypeis omitted, confirming the fix addresses the intended bugEvidence
pnpm check && pnpm lint && npx tsc --noEmit)before:
after:
Checklist