shopify-ai-backup/MISTRAL_LOGGING_CHANGES.md

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