119 lines
4.3 KiB
Markdown
119 lines
4.3 KiB
Markdown
# 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
|