Restore to commit 74e578279624c6045ca440a3459ebfa1f8d54191

MISTRAL_LOGGING_CHANGES.md

@@ -0,0 +1,118 @@
+# Mistral API Logging Changes
+
+## Overview
+Added comprehensive logging to debug and monitor Mistral API calls in the planning phase. All logs now output to container logs using `console.log()` and `console.error()` for easy debugging.
+
+## Changes Made
+
+### 1. Enhanced `sendMistralChat()` Function (lines 3187-3276)
+Added detailed logging at every stage:
+
+- **Request Initialization**:
+  - Logs API URL, model, message count
+  - Shows API key status and prefix (first 8 chars for debugging)
+  
+- **Response Handling**:
+  - Logs HTTP status, headers, and response OK status
+  - Logs detailed response structure inspection
+  - Shows if choices/message/content exist in response
+  - Logs content length and preview (first 200 chars)
+  
+- **Error Handling**:
+  - Logs full error response body on HTTP errors
+  - Logs fetch errors with stack traces
+  - Alerts when response has no content
+
+**Example log output:**
+```
+[MISTRAL] Starting API request { url: '...', model: 'mistral-large-latest', messageCount: 3 }
+[MISTRAL] Response received { status: 200, ok: true }
+[MISTRAL] Response data structure { hasChoices: true, choicesLength: 1, hasContent: true, contentLength: 523 }
+[MISTRAL] Successfully extracted reply { replyLength: 523, replyPreview: '...' }
+```
+
+### 2. Enhanced `sendMistralPlanWithFallback()` Function (lines 3366-3410)
+Added fallback chain logging:
+
+- Logs full model chain before attempting
+- Logs each model attempt
+- Logs success/failure for each model
+- Shows why fallback was triggered or broken
+- Logs final failure with all attempts
+
+**Example log output:**
+```
+[MISTRAL] Starting fallback chain { preferredModel: '', chainLength: 2, models: [...] }
+[MISTRAL] Trying model: mistral-large-latest
+[MISTRAL] Plan succeeded on first try { model: 'mistral-large-latest' }
+```
+
+### 3. Enhanced `handlePlanMessage()` Function (lines 3460-3593)
+Added end-to-end planning logging:
+
+- Logs plan chain configuration at start
+- Logs each provider attempt
+- Logs provider limits and skips
+- Logs detailed Mistral result inspection
+- Logs final success with reply preview
+- Logs comprehensive error info with stack traces
+
+**Example log output:**
+```
+[PLAN] Starting plan message handling { sessionId: '...', planChainLength: 2, providers: [...] }
+[PLAN] Trying provider { provider: 'mistral', model: '' }
+[PLAN] Using Mistral provider { modelHint: '', messagesCount: 3 }
+[PLAN] Mistral result received { hasResult: true, hasReply: true, replyLength: 523, model: '...' }
+[PLAN] Provider succeeded { provider: 'mistral', model: '...', replyLength: 523, replyPreview: '...' }
+[PLAN] Plan message completed successfully { sessionId: '...', provider: 'mistral', model: '...' }
+```
+
+### 4. Bootstrap Configuration Logging (lines 6590-6615)
+Added provider configuration display on server startup:
+
+- Shows OpenRouter configuration
+- Shows Mistral configuration (API key status, models, URL)
+- Shows planning settings
+- Helps verify environment setup
+
+**Example output:**
+```
+=== PROVIDER CONFIGURATION ===
+[CONFIG] OpenRouter: { configured: true, apiUrl: '...', primaryModel: '...' }
+[CONFIG] Mistral: { configured: true, apiUrl: '...', primaryModel: '...', hasApiKey: true, apiKeyPrefix: 'sk_test_...' }
+[CONFIG] Planning Settings: { provider: 'mistral', planningChainLength: 2, planningChain: [...] }
+==============================
+```
+
+## Log Prefixes
+
+All logs use consistent prefixes for easy filtering:
+
+- `[MISTRAL]` - Mistral API-specific operations
+- `[PLAN]` - Plan message handling
+- `[CONFIG]` - Configuration at startup
+
+## Benefits
+
+1. **Debugging**: Full visibility into API request/response cycle
+2. **Monitoring**: Easy to track provider performance
+3. **Troubleshooting**: Detailed error messages with context
+4. **Configuration Validation**: Startup logs verify settings
+5. **Container Logs**: All output goes to stdout/stderr for Docker log collection
+
+## Testing
+
+To verify logging works:
+
+1. Start the container
+2. Watch logs: `docker logs -f <container_name>`
+3. Send a plan message through the builder
+4. You should see detailed logs for each step
+
+## Common Issues Debuggable Now
+
+1. **Empty responses**: Logs will show if API returns no content
+2. **Wrong response format**: Structure inspection shows what fields exist
+3. **API errors**: Full error body and status logged
+4. **Fallback chain**: See exactly which models are tried and why they fail
+5. **Configuration issues**: Startup logs show if API keys/models are set