Add fallback LLM provider on timeout/rate-limit - #46
Open
mrunmayeekokitkar wants to merge 1 commit into
Open
Conversation
- Add secondary provider config to LLMConfig interface - Implement fallback logic in generateText and streamText - Fallback triggers on 429 (rate limit), 5xx server errors, and timeout (AbortError) - Add logging to track which provider served each request - Update AI settings UI to configure fallback provider - Add comprehensive tests for fallback mechanism - Update .env.local.example with GROQ_API_KEY
|
@mrunmayeekokitkar is attempting to deploy a commit to the suyashyadav1709-9626's projects Team on Vercel. A member of the Team first needs to authorize it. |
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
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
Implements a fallback LLM provider mechanism that automatically retries requests with a secondary provider when the primary provider encounters recoverable failures. This improves reliability during rate limiting, transient server errors, and request timeouts while allowing users to configure fallback providers directly from the AI settings page.
Related Issue
Closes #34
Changes
LLM Provider
Updated
provider.tsto support automatic fallback providers.Configuration
Extended the
LLMConfiginterface with:fallbackProviderfallbackApiKeyfallbackModelFallback Logic
Implemented automatic fallback for both:
generateText()streamText()The primary provider is attempted first. If a recoverable error occurs, the request is automatically retried using the configured fallback provider.
Fallback Conditions
Fallback is triggered for:
AbortError)Fallback is not triggered for:
429), since these generally indicate user or request configuration issues.Timeout Handling
Added
fetchWithTimeout()to enforce a 30-second timeout for provider requests.Provider Logging
Added provider logging to identify which provider handled each request.
Example log output:
This improves debugging and operational visibility.
AI Settings
Updated
ai-settings.tsxto support fallback provider configuration.Users can now:
Fallback configuration is stored alongside the primary LLM configuration.
Environment Configuration
Updated
.env.local.exampleby adding:GROQ_API_KEYThis provides an example configuration for using Groq as a secondary LLM provider.
Testing
Created:
llm-fallback.test.tsAdded 8 comprehensive tests covering:
AbortError)All tests pass successfully.
Fallback Behavior
Fallback occurs for:
AbortError)Fallback does not occur for:
Implementation Summary
provider.tsLLMConfigwith fallback configuration.shouldUseFallback()helper.logProvider()helper.fetchWithTimeout().generateText()streamText()ai-settings.tsx.env.local.exampleGROQ_API_KEY.Tests
Created:
llm-fallback.test.tswith comprehensive fallback coverage.
Checklist
npm run lintpasses successfully.npm run testpasses successfully.Screenshots (if applicable)
N/A
Acceptance Criteria
Additional Notes
The fallback mechanism automatically improves reliability without changing the existing API surface. Requests continue to use the primary provider by default, with seamless failover only for recoverable failures such as rate limits, transient server errors, and timeouts.