Skip to content

fix(llmcore): 添加MiniMax超时错误码529支持重试机制#89

Merged
lsdefine merged 1 commit intolsdefine:mainfrom
mmgnosit-commits:fix/minimax-timeout-retry
Apr 18, 2026
Merged

fix(llmcore): 添加MiniMax超时错误码529支持重试机制#89
lsdefine merged 1 commit intolsdefine:mainfrom
mmgnosit-commits:fix/minimax-timeout-retry

Conversation

@mmgnosit-commits
Copy link
Copy Markdown

问题描述

MiniMax API在请求超时时返回HTTP 529状态码,该状态码未被包含在可重试状态码集合中, 导致即使配置了max_retries参数,重试机制也对MiniMax超时无效。

  • 当前行为:MiniMax 529 → 不重试 → 直接报错
  • 预期行为:MiniMax 529 → 触发重试逻辑 → max_retries生效

解决方案

在llmcore.py的RETRYABLE集合中添加529状态码。

关于其他改动的思考

最初的想法是:将 LLM API 重试的 HTTP 状态码从硬编码提取为可配置文件 assets/http_retry_codes.json,首次运行时自动生成默认配置

之前的初衷(配置文件方案)

  • ✓ 不修改代码即可适配新的错误码
  • ✓ 降低维护成本

现实考量(硬编码方案)

  • 主流模型厂商就那几家:OpenAI、Claude、MiniMax、Kimi等 - 标准的超时错误码基本固化:408(timeout)、429(rate_limit)、5xx(server_error)
  • MiniMax 529是特例但不频繁变化
  • 硬编码更简洁直接,维护更清晰

受影响范围

  • llmcore.py: _openai_stream() 函数的重试机制现在支持MiniMax 529错误
  • 对应MiniMax API的超时场景现在能正确触发retry逻辑

## 问题描述
MiniMax API在请求超时时返回HTTP 529状态码,该状态码未被包含在可重试状态码集合中, 导致即使配置了max_retries参数,重试机制也对MiniMax超时无效。
当前行为:MiniMax 529 → 不重试 → 直接报错
预期行为:MiniMax 529 → 触发重试逻辑 → max_retries生效 ## 解决方案
在llmcore.py的RETRYABLE集合中添加529状态码。 ## 关于其他改动的思考 最初的想法是:将 LLM API 重试的 HTTP 状态码从硬编码提取为可配置文件
assets/http_retry_codes.json,首次运行时自动生成默认配置

### 之前的初衷(配置文件方案)
- ✓ 不修改代码即可适配新的错误码
- ✓ 降低维护成本
### 现实考量(硬编码方案)
- 主流模型厂商就那几家:OpenAI、Claude、MiniMax、Kimi等 -
标准的超时错误码基本固化:408(timeout)、429(rate_limit)、5xx(server_error)
- MiniMax 529是特例但不频繁变化
- 硬编码更简洁直接,维护更清晰

## 受影响范围
- llmcore.py: _openai_stream() 函数的重试机制现在支持MiniMax 529错误
- 对应MiniMax API的超时场景现在能正确触发retry逻辑
@lsdefine lsdefine merged commit 184948b into lsdefine:main Apr 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants