139 lines
5.0 KiB
Markdown
139 lines
5.0 KiB
Markdown
# Mistral Response Parsing and Logging Fix
|
|
|
|
## Problem
|
|
When Mistral is set as the planning model, users get no response. The issue appears to be related to API response parsing in the `sendMistralChat()` function, though the response structure parsing looks correct according to Mistral API documentation.
|
|
|
|
## Solution
|
|
Added comprehensive logging throughout the Mistral API call chain to diagnose the exact issue. The logging will help identify:
|
|
|
|
1. Whether the API call is being made correctly
|
|
2. The actual response structure returned by Mistral API
|
|
3. Whether content extraction is working properly
|
|
4. If the reply is being lost during sanitization or message creation
|
|
5. Any errors being swallowed silently
|
|
|
|
## Changes Made
|
|
|
|
### 1. Enhanced `sendMistralChat()` Function (server.js ~lines 3200-3290)
|
|
|
|
**Request Logging:**
|
|
- Added detailed request payload logging including:
|
|
- Model being used
|
|
- Message count and structure
|
|
- First and last message previews
|
|
- Content lengths
|
|
|
|
**Response Logging:**
|
|
- Full raw API response as JSON (complete visibility)
|
|
- Response structure analysis (choices, message, content)
|
|
- Step-by-step content extraction with type checks at each level:
|
|
- `data?.choices` (array)
|
|
- `data?.choices?.[0]` (first choice)
|
|
- `data?.choices?.[0]?.message` (message object)
|
|
- `data?.choices?.[0]?.message?.content` (content string)
|
|
- `typeof` at each extraction step
|
|
|
|
**Reply Analysis:**
|
|
- Comprehensive reply value logging:
|
|
- Raw reply value
|
|
- Type of reply
|
|
- Length
|
|
- Boolean checks: isEmpty, isNull, isUndefined, isFalsy
|
|
- Enhanced error logging with full data dump if no content found
|
|
|
|
### 2. Enhanced `sendMistralPlanWithFallback()` Logging (server.js ~lines 3505-3516)
|
|
|
|
**Result Tracking:**
|
|
- Log full result object as JSON
|
|
- Log all result object keys
|
|
- Log raw reply value and type
|
|
- Log reply length before any processing
|
|
|
|
### 3. Enhanced `handlePlanMessage()` Logging (server.js ~lines 3539-3640)
|
|
|
|
**Sanitization Tracking:**
|
|
- Log reply value BEFORE sanitization (raw from API)
|
|
- Log reply value AFTER sanitization
|
|
- Compare to detect if sanitization is modifying/removing content
|
|
|
|
**Message Creation Tracking:**
|
|
- Log reply when creating message object
|
|
- Log final message object details (messageId, reply, lengths)
|
|
- Log plan summary that will be stored in session
|
|
|
|
**Completion Tracking:**
|
|
- Log full details when plan message completes successfully
|
|
- Include provider, model, reply lengths
|
|
|
|
## What This Logging Will Reveal
|
|
|
|
With these logs, you'll be able to see:
|
|
|
|
1. **API Request Issues:**
|
|
- If the API URL is wrong
|
|
- If the API key is invalid
|
|
- If the payload format is incorrect
|
|
|
|
2. **API Response Issues:**
|
|
- If Mistral returns a different structure than expected
|
|
- If the response contains errors not caught by error handling
|
|
- If content is in a different field than `choices[0].message.content`
|
|
|
|
3. **Parsing Issues:**
|
|
- At which step the content extraction fails
|
|
- If the content is undefined, null, or empty string
|
|
- Type mismatches
|
|
|
|
4. **Processing Issues:**
|
|
- If sanitization is removing the content
|
|
- If the reply gets lost during message creation
|
|
- If plan summary is not being set correctly
|
|
|
|
## How to Use
|
|
|
|
1. Set Mistral as the planning provider in admin panel
|
|
2. Try to create a plan with a user message
|
|
3. Check Docker logs for `[MISTRAL]` and `[PLAN]` prefixes
|
|
4. Look for the full API response to see what Mistral actually returns
|
|
5. Follow the reply value through each step to see where it disappears
|
|
|
|
## Example Log Output
|
|
|
|
You should see logs like:
|
|
```
|
|
[MISTRAL] Starting API request { url: '...', model: '...', ... }
|
|
[MISTRAL] Request payload: { model: '...', messagesCount: 3, ... }
|
|
[MISTRAL] Response received { status: 200, ok: true, ... }
|
|
[MISTRAL] Full API response: { "choices": [...], ... }
|
|
[MISTRAL] Choices array: [...]
|
|
[MISTRAL] First choice: { ... }
|
|
[MISTRAL] Message object: { ... }
|
|
[MISTRAL] Content value: "actual content here"
|
|
[MISTRAL] Content type: "string"
|
|
[MISTRAL] Extracted reply: { reply: "...", replyType: "string", ... }
|
|
[PLAN] Mistral result received (raw): { hasResult: true, ... }
|
|
[PLAN] Before sanitization: { rawReply: "...", ... }
|
|
[PLAN] After sanitization: { sanitizedReply: "...", ... }
|
|
[PLAN] Creating message object with reply: { reply: "...", ... }
|
|
[PLAN] Final message details: { messageId: "...", messageReply: "...", ... }
|
|
[PLAN] Plan message completed successfully { ... }
|
|
```
|
|
|
|
## Next Steps
|
|
|
|
After running a test with Mistral as the planning provider:
|
|
|
|
1. Share the Docker logs (filter by `[MISTRAL]` and `[PLAN]`)
|
|
2. Look specifically for the "Full API response" log
|
|
3. Check if the content extraction shows any undefined/null values
|
|
4. Verify if the reply makes it all the way to the final message
|
|
|
|
This comprehensive logging should reveal exactly where and why the response is being lost.
|
|
|
|
## Files Modified
|
|
|
|
- `/home/engine/project/chat/server.js`
|
|
- `sendMistralChat()` function (~lines 3200-3290)
|
|
- `sendMistralPlanWithFallback()` function (already had logging, enhanced at ~3505-3516)
|
|
- `handlePlanMessage()` function (~lines 3539-3640)
|