[Bug Report] 429 限流不自动恢复：dsh-llm-retry 在网关 Retry-After 超过默认 maxDelayMs（10s）时直接放弃重试

[DRAG0NM]

摘要

企业/自建 LLM 网关带流控（429 + Retry-After）时，dsh 触发限流后不会自动恢复：dsh-llm-retry 的 normal 重试模式在 providerRetryAfterMs > policy.maxDelayMs（默认 10s）时直接 return next() 放弃（lib/index.js L146-147），错误原样上抛、turn 终止——用户看到的就是"卡在那里，不自动恢复"（#891）。对比 claude code/zcode 会等待 Retry-After 窗口后再重试。企业网关的流控窗口（30-60s 常见）几乎必然超过 10s 上限，因此该缺陷在流控网关上是确定性必现。

复现步骤

1. 配置一个 429 时返回 Retry-After: 30（或任何 >10 的值）的网关（企业流控网关常见行为）。
2. 让模型发起请求直到触发限流。
3. 结果：第一次 429 后 dsh 不等待、立即放弃（无第 2、3 次尝试），turn 以错误结束；会话停在失败状态，需要用户手动重发——触发429限流后不会自动恢复 #891 原现象（"dsh 不会 [重试]，会直接卡在那里"）。
4. 对照：Retry-After ≤ 10s 时 dsh 会按该值等待并重试（≤2 次）——证明断点就在上限比较处。

根因（源码定位，rc.6）

@deepseek-ai/dsh-llm-retry/lib/index.js recover()（L129-152）：

} else if (!policy.retryableCodes.includes(failure.code)) return next();   // L138：RATE_LIMIT 在可重试集内，继续
...
let delayMs;
if (failure.providerRetryAfterMs !== void 0 && ... ) if (failure.providerRetryAfterMs > policy.maxDelayMs) {
    if (policy.mode === "normal") return next();                          // L146-147 ← 根因：>10s 直接放弃
    delayMs = localDelay(policy, retry, random);
} else delayMs = failure.providerRetryAfterMs;                            // ≤10s 才按 Retry-After 等待
else delayMs = localDelay(policy, retry, random);

• 默认策略（dsh-llm L356-366）：maxRetries=2、initialDelayMs=500、maxDelayMs=1e4（10s）。
• 适配器侧已正确读取 Retry-After 并携带（dsh-llm-deepseek L601-606）——丢失发生在重试决策层：normal 模式下 Retry-After 大于本地退避上限即视为"不可等"，直接放弃。
• 语义问题：maxDelayMs 是本地退避的上限，却被用来否决服务端明确告知的重试时间——网关自己知道何时恢复，dsh 却拒绝等它。

建议修复

方案 A（推荐）· 允许等待服务端 Retry-After，另设绝对上限：normal 模式下
providerRetryAfterMs > maxDelayMs 不再直接放弃，而是按 providerRetryAfterMs
等待（受新的独立绝对上限约束，如 maxProviderRetryAfterMs 默认 5 分钟）：

if (failure.providerRetryAfterMs > policy.maxDelayMs) {
    if (failure.providerRetryAfterMs > (policy.maxProviderRetryAfterMs ?? 3e5)) return next();
    delayMs = failure.providerRetryAfterMs;   // 服务端说了算
}

maxDelayMs 继续约束本地指数退避；服务端 Retry-After 走自己的上限。一处修复恢复
企业流控网关的自动恢复能力。

方案 B · 配置面：允许部署方单独配置 retryAfterCapMs（或提高 maxDelayMs），
并保持"超过上限时明确提示"——至少给出可执行的配置建议而非静默放弃。

方案 C（日志）：放弃时记录明确原因
（"gateway asked to retry after ${n}s but maxDelayMs=${m}s — raise maxDelayMs"），
当前静默 return next() 让用户无从得知为何不重试。

影响

• 所有带流控的企业/自建网关（429 + Retry-After > 10s）在 dsh 上确定性失败且
  不自动恢复，需人工重发（触发429限流后不会自动恢复 #891；claude code/zcode 同场景可自动恢复）
• 重试预算本身（2 次、10s 上限）对长流控窗口也偏小，放大了放弃概率
• 与限流窗口"错过重试时机 → 继续 429 → 再次放弃"形成负反馈，会话体验为卡死

环境

• 源码定位：0.1.0-rc.6（dsh-llm-retry/lib/index.js L129-152、dsh-llm L356-366、
  dsh-llm-deepseek L601-606；Node v24.16.0，Windows 11）
• 原报告：触发429限流后不会自动恢复 #891（0 评论，此前无人分析）

验证材料

• 根因节行号与关键代码：L146-147 的 return next() 分支、L138 的 RATE_LIMIT 放行、
  L601-606 的 Retry-After 携带（证明信息在、决策层丢弃）
• 对照逻辑：Retry-After ≤ 10s 时按服务端时间等待（L149）——同一函数内两种行为，
  差异仅在阈值比较
• 复现：任意返回 Retry-After: 30 的 429 网关即可观察"不等待、直接失败"

---

First source-located analysis of discussion #891. Happy to open a PR with fix option A.