# 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)
