fix: use Mistral SDK with automatic rate-limit handling #83

Merged

jonas.hanisch merged 1 commit from fix/mistral-rate-limit-sdk into main

2026-01-22 18:47:05 +00:00

jack commented

2026-01-22 18:46:18 +00:00

Owner

Summary

Replaces raw fetch() calls with the official @mistralai/mistralai SDK
SDK provides built-in retry with exponential backoff for 429 rate-limit errors
Configured: 2s initial interval, max 60s between retries, 5min total timeout
Fixes generator restart loops caused by Mistral rate limits

Problem

When using Mistral as the observation extraction provider, hitting rate limits (HTTP 429) would cause the generator to fail and restart. After exceeding MAX_CONSECUTIVE_RESTARTS=3, the worker would stop processing entirely, leaving messages stuck in the queue.

Solution

The official Mistral SDK handles rate limits automatically via its retryConfig option. The SDK waits and retries with exponential backoff, preventing the generator from crashing on transient rate limit errors.

new Mistral({
  apiKey,
  retryConfig: {
    strategy: 'backoff',
    backoff: {
      initialInterval: 2000,   // 2 seconds
      maxInterval: 60000,      // max 60 seconds
      exponent: 2,             // double each retry
      maxElapsedTime: 300000,  // give up after 5 minutes
    },
    retryConnectionErrors: true,
  },
});

Test plan

Queue processes without errors when rate limits are hit
Worker status shows decreasing queue depth
No generator restart loops observed

🤖 Generated with Claude Code

## Summary - Replaces raw `fetch()` calls with the official `@mistralai/mistralai` SDK - SDK provides built-in retry with exponential backoff for 429 rate-limit errors - Configured: 2s initial interval, max 60s between retries, 5min total timeout - Fixes generator restart loops caused by Mistral rate limits ## Problem When using Mistral as the observation extraction provider, hitting rate limits (HTTP 429) would cause the generator to fail and restart. After exceeding `MAX_CONSECUTIVE_RESTARTS=3`, the worker would stop processing entirely, leaving messages stuck in the queue. ## Solution The official Mistral SDK handles rate limits automatically via its `retryConfig` option. The SDK waits and retries with exponential backoff, preventing the generator from crashing on transient rate limit errors. ```typescript new Mistral({ apiKey, retryConfig: { strategy: 'backoff', backoff: { initialInterval: 2000, // 2 seconds maxInterval: 60000, // max 60 seconds exponent: 2, // double each retry maxElapsedTime: 300000, // give up after 5 minutes }, retryConnectionErrors: true, }, }); ``` ## Test plan - [x] Queue processes without errors when rate limits are hit - [x] Worker status shows decreasing queue depth - [x] No generator restart loops observed 🤖 Generated with [Claude Code](https://claude.com/claude-code)

jack added 1 commit

2026-01-22 18:46:18 +00:00

fix: use Mistral SDK with automatic rate-limit handling

CI / build (pull_request) Successful in 21s

Details

CI / validate-plugin (pull_request) Successful in 2s

Details

a33b2176a4

Replaces raw fetch() calls with the official @mistralai/mistralai SDK
which provides built-in retry with exponential backoff for 429 errors.

- Add @mistralai/mistralai dependency
- Refactor MistralAgent to use SDK client with retryConfig
- Configure exponential backoff: 2s initial, max 60s, 5min timeout
- SDK automatically handles rate limits without generator restarts

This fixes the issue where Mistral rate limits (429) caused generator
restart loops that could exceed the MAX_CONSECUTIVE_RESTARTS limit.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>