classifyPiAiError 中 401|403 正则顺序抢走 429，限流被误判为不可重试的 AUTH

[use-A33]

摘要

classifyPiAiError() 用纯文本正则判断错误类别，且 401|403 的分支排在 429 之前。当错误消息正文里同时含 401 与 429 字样（或含 401 的包装文本）时，请求会被归类为 AUTH（不可重试），而真实原因是上游限流（应可重试）。

问题位置

packages/llm/llm-pi-ai/src/stream.ts（约 42–45 行）：

function classifyPiAiError(message: string): string {
  if (/\b(?:401|403)\b/.test(message)) return 'AUTH'        // ← 排最前、纯文本匹配
  if (isQuotaExceededError(message)) return QUOTA_EXCEEDED_CODE
  if (/\b429\b|rate.?limit/i.test(message)) return 'RATE_LIMIT'
  …

影响

401|403 既排最前、又只做文本匹配。消息里任何 401 字样（包括被包装进 message 的嵌套 JSON）都会抢走 429 判断，把可重试的限流误判为不可重试的认证失败——用户侧表现为"API 密钥无效"，实际密钥有效。

复现路径（真实案例）

provider 插件 dsh-workbuddy-connect-functy 在"账号池暂时为空"时，返回带 401 字样的包装消息，同时底层上游是 429（账号标识已脱敏为 <account>）：

401: {"message":"workbuddy upstream session_dead (http 0): no WorkBuddy account is currently usable (…)"
      ,"type":"not_signed_in","code":"not_signed_in"}

该消息同时命中 401 与（上游真实）429 语义，classifyPiAiError 返回 AUTH，宿主随即终止重试。修正来源侧后，同一诱因下分类正确变为 RATE_LIMIT，重试正常启动。

说明：错误消息本身不含任何访问令牌；涉及的账号 UID 已在本文中脱敏为 <account>。

建议修复

• 调整优先级：把 429/限流判断提到 401|403 之前；或
• 结构化分类：优先依据 HTTP 状态码 / 错误对象字段判断，而非 message 文本。

参考改法（最小改动）：

-  if (/\b(?:401|403)\b/.test(message)) return 'AUTH'
-  if (isQuotaExceededError(message)) return QUOTA_EXCEEDED_CODE
-  if (/\b429\b|rate.?limit/i.test(message)) return 'RATE_LIMIT'
+  if (/\b429\b|rate.?limit/i.test(message)) return 'RATE_LIMIT'
+  if (isQuotaExceededError(message)) return QUOTA_EXCEEDED_CODE
+  if (/\b(?:401|403)\b/.test(message)) return 'AUTH'

环境

• @deepseek-ai/dsh-root 0.2.1-alpha.2（master，d743267…）
• 相关 provider：dsh-workbuddy-connect-functy 0.13.11

[argszero]

Confirmed at packages/llm/llm-pi-ai/src/stream.ts (master @ d743267388): /\b(?:401|403)\b/ is the first test in classifyPiAiError, every test is an unanchored substring match, and the first match wins. Your reading of the consequence is also right — DEFAULT_RETRYABLE_CODES is [EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT] (packages/llm/llm/src/retry-policy.ts) and llm-retry decides on nothing but the code (packages/llm/llm-retry/src/index.ts:215), so an AUTH verdict ends the step.

The fragility is wider than 401-versus-429. Because ordering is the rule, several pairs collide the same way and 401/403 is only the first instance:

• \b400\b|invalid.?request sits above \b5\d\d\b and above the timeout and transport tests — a wrapper that echoes a 400 next to a 503/504/timeout is INVALID_REQUEST, hence non-retryable, for the same reason.
• isQuotaExceededError sits above 429|rate.?limit, so a message naming both an exhausted quota and 429 is QUOTA (also outside the retryable set) rather than RATE_LIMIT.
• Any 5\d\d anywhere beats the timeout and transport tests.

Why it is text-matching at all — the adapter's own comment above the function answers it: pi-ai flattens the caught error to error.message and discards the original Error and its cause chain before it reaches the harness, so the actionable transport detail is already gone. The ordering is a stopgap inside that constraint; the durable fix is pi-ai forwarding the original error (or a fetch/dispatcher hook the harness can classify on) — which is what your second suggestion amounts to.

Available today without touching core. @argszero/cordis-plugin-empty-response-retry exists for exactly this family — a failure whose code does not name what actually happened, made retryable on the seam that sees the attempt. It ships the knob your case needs: transientCodes (codes to re-examine) plus transientMessages (patterns that prove the opposite) with transientTargetCode (default SERVER, which is retryable). Unlike its other recognition arms, that one has no zero-output gate, because it is a claim about the route rather than about the attempt's output. So for a wrapping provider plugin whose wording keeps landing in AUTH, transientCodes: ['PI_AI_ERROR', 'AUTH'] plus that wrapper's pattern is the workaround — keep the pattern narrow, since each match spends a retry. vetoMessages is evaluated first, so a wording that names a subscription limit is still refused.

To be clear, that is a mitigation for third-party wrappers, not an argument against reordering the chain: the ordering is the defect, and the reorder is the right upstream change.