Parent Epic: #56
Related: #61 (Azure), #62, #63
🎯 Goal
To refactor the existing "Test Connection" button so it can dynamically validate credentials for all supported provider_type (OpenAI, Azure, Gemini, Open Router), not just the default OpenAI format.
🐛 Current Problem
The "Test Connection" button already exists, but its backend logic is hard-coded to send a test request only in the format expected by the standard OpenAI API.
This means:
- When a user correctly configures an Azure provider and clicks "Test," the test fails because the backend doesn't send the
api-version or use the correct endpoint structure.
- This will also fail for Gemini and Open Router as they have unique API formats.
⚙️ Backend Requirements
The "Test Connection" API endpoint (e.g., /api/model/test-connection) must be refactored:
- Read Provider Type: The endpoint must receive the entire form configuration from the frontend, including the
provider_type (OpenAI, Azure, Gemini, etc.).
- Dynamic Dispatch: The backend must use the
provider_type to determine which test logic to run. A switch statement or factory pattern is recommended.
- Case 'OpenAI': Use the existing validation logic.
- Case 'Azure': Use the Azure-specific logic (e.g., attempt a simple chat completion using the
Endpoint, Deployment ID, API Key, and API Version).
- Case 'Gemini': Use Gemini-specific logic (e.g., call
generateContent with the API Key).
- Case 'OpenRouter': Use OpenRouter-specific logic (e.g., make a request with the
Authorization and HTTP-Referer headers).
- Unified Response: The endpoint must return a standardized JSON response, regardless of the provider tested:
{ success: true }
{ success: false, error: "Connection failed: [Specific error from the provider]" }
💻 UI Requirements (Frontend)
- No new UI elements are needed (the button already exists).
- The frontend "Test Connection" button's click handler must be updated to send the entire form state (including the selected
provider_type) to the backend test endpoint.
✅ Acceptance Criteria
- The "Test Connection" button continues to work correctly for standard OpenAI configurations.
- The "Test Connection" button now works correctly for a valid Azure configuration.
- The "Test Connection" button now works correctly for a valid Gemini configuration.
- The "Test Connection" button now works correctly for a valid Open Router configuration.
- If a test fails for any provider, a clear error message from that provider is shown to the user.
Parent Epic: #56
Related: #61 (Azure), #62, #63
🎯 Goal
To refactor the existing "Test Connection" button so it can dynamically validate credentials for all supported
provider_type(OpenAI, Azure, Gemini, Open Router), not just the default OpenAI format.🐛 Current Problem
The "Test Connection" button already exists, but its backend logic is hard-coded to send a test request only in the format expected by the standard OpenAI API.
This means:
api-versionor use the correct endpoint structure.⚙️ Backend Requirements
The "Test Connection" API endpoint (e.g.,
/api/model/test-connection) must be refactored:provider_type(OpenAI, Azure, Gemini, etc.).provider_typeto determine which test logic to run. Aswitchstatement or factory pattern is recommended.Endpoint,Deployment ID,API Key, andAPI Version).generateContentwith theAPI Key).AuthorizationandHTTP-Refererheaders).{ success: true }{ success: false, error: "Connection failed: [Specific error from the provider]" }💻 UI Requirements (Frontend)
provider_type) to the backend test endpoint.✅ Acceptance Criteria