Integration/pr 4950 5147 #5477
Closed
Integration/pr 4950 5147 #5477
Conversation
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
- Make API Key Tester the only grey container (bg-background-muted) - Arrange Tetrate and OpenRouter side-by-side in grid layout - Add 'Other Providers' section with link to settings - Use transparent backgrounds for provider cards - Improve visual hierarchy and spacing - Add provider icons to each card - Maintain hover effects and transitions Layout now follows: [Quick Setup with API Key] (grey) [Tetrate] [OpenRouter] (transparent, side-by-side) [Other Providers] (transparent)
- Change /settings/providers to /configure-providers - Fixes 'No routes matched location' error in console - Allows 'Other Providers' button to work properly
- Add DESIGN_SUMMARY.md with layout improvements overview - Add INTEGRATION_COMPLETE.md with full integration details - Add ROUTE_FIX_INSTRUCTIONS.md for troubleshooting - Update API client files from regeneration
- Remove integration documentation files (kept locally for reference) - Remove backup files - Keep only production code changes
- Replace 'error: any' with 'error: unknown' - Add proper ApiError interface for type safety - Improve error handling with proper type guards - Fixes ESLint @typescript-eslint/no-explicit-any warning
- Reorder imports alphabetically in config_management.rs - Move auto_detect import to correct position in mod.rs - Remove extra blank lines - Fixes cargo fmt --check validation
Backend changes: - Detect provider from key format first (sk-ant- = Anthropic, sk- = OpenAI, etc.) - Only test the detected provider instead of all providers - Return structured error responses with suggestions - Add DetectProviderError struct with detailed feedback Frontend changes: - Handle new structured error responses - Show provider-specific error messages - Display helpful suggestions when validation fails - Improve loading state to show 'Testing API key...' Fixes issue where wrong keys would test against all providers. Now users get clear feedback about their specific key type.
- Add userInActiveSetup state to track when user is actively testing keys - Prevent ProviderGuard from redirecting when user is in setup flow - Add onStartTesting callback to ApiKeyTester component - Fix useEffect dependencies to include userInActiveSetup - Add frontend rejection of Ollama fallbacks in Quick Setup - Add specific handling for OpenRouter keys (sk-or- format) - Remove suggestions box and test results header for cleaner UI - Add debug logging for troubleshooting Fixes issue where users entering incorrect API keys would see error but then get redirected to existing provider configurations instead of staying on setup screen to retry.
- Add disable_ollama_fallback parameter to DetectProviderRequest - Update auto_detect function to respect fallback disable flag - Update OpenAPI schema and TypeScript types - Prepare for future backend compilation Note: These backend changes require Rust recompilation to take effect. Frontend workarounds are in place until backend can be rebuilt.
- Replace format-based detection with parallel testing approach - Test all providers simultaneously using tokio::spawn for better accuracy - Simplify API response (404 for no match instead of structured errors) - Remove complex Ollama rejection logic - let parallel testing handle it - Should properly detect Anthropic, OpenAI, Google, Groq, xAI, and Ollama - Maintains existing Quick Setup UI with improved backend detection This integrates the robust parallel testing approach from PR #5147 into our Quick Setup onboarding flow for better API key detection.
- Add detect_cloud_provider_from_api_key() function that excludes Ollama - Add /config/detect-cloud-provider endpoint for Quick Setup use - Update ApiKeyTester to use cloud-only detection endpoint - Remove frontend Ollama rejection since backend won't return it - Ensures Quick Setup only works with cloud API providers - Maintains full detection (including Ollama) for other use cases This prevents unwanted Ollama fallbacks in Quick Setup while preserving the parallel testing approach from PR #5147 for better accuracy.
The new /config/detect-cloud-provider endpoint requires backend recompilation. Until then, use the existing /config/detect-provider endpoint with frontend filtering to reject Ollama results in Quick Setup. - Use detectProvider() instead of detectCloudProvider() - Add frontend Ollama rejection back - Maintains cloud-only behavior for Quick Setup - Works with current compiled backend
- Change from module import to specific function imports - Fix function calls to not use module prefix - Resolves compilation error for detect_cloud_provider_from_api_key This allows the backend to compile with the new cloud-only detection endpoint when the Rust code is recompiled.
The Ollama rejection logic was accidentally removed in previous changes. This adds it back to prevent unwanted Ollama fallbacks in Quick Setup. - Reject any Ollama detection results in Quick Setup flow - Show proper error message for cloud providers only - Return early to prevent success flow execution - Maintains focus on cloud API providers for Quick Setup
The pure parallel approach from PR #5147 was testing Anthropic keys against OpenAI API, causing incorrect rejections. This hybrid approach: 1. Detects key format first (sk-ant- → anthropic) 2. Tests the likely provider first with the key 3. Falls back to parallel testing if format detection fails 4. Includes OpenRouter support (sk-or- format) This should correctly route sk-ant- keys to Anthropic API for proper validation while maintaining the robustness of parallel testing for unknown formats. Benefits: - Anthropic keys test against Anthropic API (not OpenAI) - Faster detection (test likely provider first) - Robust fallback (parallel testing if needed) - Supports more providers (OpenRouter)
Since backend hybrid detection requires recompilation, add frontend format detection to provide better error messages and debugging. - Detect key format on frontend (sk-ant- → Anthropic, etc.) - Provide format-specific error messages when validation fails - Add debugging to show detected format and key analysis - Better user guidance based on detected provider format This helps users understand why their keys are failing validation even when the backend is still using the old parallel-only approach.
- Enhanced frontend format detection for all major providers (Anthropic, OpenRouter, OpenAI, Google, Groq, xAI) - Added smart workarounds for backend parallel testing issues - Prevent unwanted redirects during API key testing by maintaining userInActiveSetup state - Reject Ollama fallback in Quick Setup to ensure cloud-only provider detection - Configure providers directly when backend detection fails but format is recognized - Use correct model names: claude-3-haiku-20240307 for Anthropic, anthropic/claude-3-haiku for OpenRouter - Add input validation to prevent console log injection issues - Provide detailed error messages and suggestions for failed key validation - Integrate parallel testing approach from PR #5147 with frontend filtering Fixes the core issue where users entering incorrect API keys would be redirected away from setup screen, now they stay on setup with clear error feedback.
- Replace problematic key generation that could result in null or duplicate keys
- Use fallback key pattern: message.id || `message-${index}-${role}`
- Ensures unique keys across all message components to prevent React warnings
- Fixes: 'Encountered two children with the same key, null' warning
This resolves the React warning that appeared when switching between providers
or when messages lacked proper IDs.
- Update Anthropic model from claude-3-haiku-20240307 to claude-3-opus-20240229 - Update OpenRouter model from anthropic/claude-3-haiku to anthropic/claude-3-opus - Update success messages to reflect Claude Opus selection - Provides users with the most capable Claude model by default This gives users access to Claude 4's enhanced capabilities for better code generation, analysis, and problem-solving performance.
- Change Anthropic model to claude-sonnet-4-0 (correct model identifier) - Update OpenRouter model to anthropic/claude-sonnet-4-0 - Update success messages to reflect Claude Sonnet selection - Ensures compatibility with the latest Claude Sonnet 4 model This uses the proper model identifier for Claude Sonnet 4 as specified.
- Add OpenAI provider handling to smart workarounds for both Ollama fallback and 404 cases - Set default OpenAI model to gpt-4.1 for optimal performance - Configure OPENAI_API_KEY, GOOSE_PROVIDER=openai, GOOSE_MODEL=gpt-4.1 - Add success message: 'Configured OpenAI with GPT-4.1 model' - Ensures OpenAI keys get proper configuration even when backend detection fails Now all major providers (OpenAI, Anthropic, OpenRouter) have smart workarounds with high-quality default models: GPT-4.1, Claude Sonnet 4, and Claude Sonnet 4 via OpenRouter.
Collaborator
|
closing this as @zanesq is taking this over I understand |
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
Type of Change
Testing
Related Issues
#4950
#5147