499识别错误

[Zeuyel]

Endpoint 报错为

503 Service Unavailable

但是错误识别为 499 并且 此错误不计入供应商熔断器 导致 频繁重试，且不会切换渠道。这个499的错误码设置有什么意义？

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

⚠️ Possible Duplicate Issue

• [BUG]错误的499识别与错误请求传递 #460

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[github-actions]

Thank you for reporting this issue.

Analysis:

Based on my investigation of the codebase, I've identified the root cause of this problem. The issue occurs in the error handling flow when the upstream endpoint returns a 503 Service Unavailable error.

Root Cause:

The problem is in src/app/v1/_lib/proxy/forwarder.ts (lines 1588-1606). When a client abort error is detected using isClientAbortError(), the code throws a ProxyError with status code 499:

// Line 1589-1606
if (isClientAbortError(err)) {
  // ...
  throw new ProxyError(
    err.name === "ResponseAborted"
      ? "Response transmission aborted"
      : "Request aborted by client",
    499 // Nginx uses "Client Closed Request" status code
  );
}

The isClientAbortError() function in src/app/v1/_lib/proxy/errors.ts (lines 617-636) uses a whitelist approach to detect client aborts:

export function isClientAbortError(error: Error): boolean {
  // 1. Check error name (most reliable)
  if (error.name === "AbortError" || error.name === "ResponseAborted") {
    return true;
  }

  // 2. Check HTTP status code (Nginx "Client Closed Request")
  if (error instanceof ProxyError && error.statusCode === 499) {
    return true;
  }

  // 3. Check exact error messages (whitelist mode)
  const abortMessages = [
    "This operation was aborted",
    "The user aborted a request",
    "aborted",
  ];

  return abortMessages.some((msg) => error.message.includes(msg));
}

The Problem:

When the upstream returns a 503 Service Unavailable error, if the error message happens to contain the word "aborted" (which can occur in various error scenarios), the isClientAbortError() function incorrectly identifies it as a client abort error. This causes:

1. The error to be reclassified as status code 499
2. The error to be categorized as ErrorCategory.CLIENT_ABORT (line 780-781 in errors.ts)
3. The circuit breaker to NOT record this failure (since client aborts are not counted)
4. Frequent retries because the system thinks the client disconnected rather than the provider failing

Circuit Breaker Bypass:

In forwarder.ts (lines 388-416), when an error is categorized as CLIENT_ABORT, the code immediately throws the error without calling recordFailure():

if (errorCategory === ErrorCategory.CLIENT_ABORT) {
  // ... logging ...
  // Does NOT call recordFailure() - directly throws
  throw lastError;
}

To help diagnose this further, please provide:

• The complete error response body from the upstream provider (if available in logs)
• The exact error message that appears in your logs
• Whether this happens consistently with a specific provider or across multiple providers

Potential workaround:

Until this is fixed, you can try enabling network error counting towards the circuit breaker by setting the environment variable:

ENABLE_CIRCUIT_BREAKER_ON_NETWORK_ERRORS=true

However, this is a partial workaround as the core issue is the overly broad "aborted" string matching in the client abort detection logic.

---

Automated response from Claude AI

[Zeuyel]

1. The response body are:

{"error":{"message":"所有供应商暂时不可用，请稍后重试","type":"service_unavailable_error","param":"","code":"service_unavailable_error"}}

it returned immediately without any features that should be routed to the 499 error. My question is that why not just use the response status code? Adding this detector bring many unpredictable errors.

2. The logs in the console of the providers is : 所有供应商暂时不可用，请稍后重试
3. Multiple providers are occurring the same wrong detect situations.

[ding113]

1. The response body are:

{"error":{"message":"所有供应商暂时不可用，请稍后重试","type":"service_unavailable_error","param":"","code":"service_unavailable_error"}}

it returned immediately without any features that should be routed to the 499 error. My question is that why not just use the response status code? Adding this detector bring many unpredictable errors.

2. The logs in the console of the providers is : 所有供应商暂时不可用，请稍后重试
3. Multiple providers are occurring the same wrong detect situations.

您好，您提供的是CCH 暴露给客户端的报错。
请问是否可以在请求详情里找到上游给 CCH 传递的完整报错信息以便排查？

[Zeuyel]

1. The response body are:

{"error":{"message":"所有供应商暂时不可用，请稍后重试","type":"service_unavailable_error","param":"","code":"service_unavailable_error"}}

it returned immediately without any features that should be routed to the 499 error. My question is that why not just use the response status code? Adding this detector bring many unpredictable errors.

2. The logs in the console of the providers is : 所有供应商暂时不可用，请稍后重试
3. Multiple providers are occurring the same wrong detect situations.

您好，您提供的是CCH 暴露给客户端的报错。
请问是否可以在请求详情里找到上游给 CCH 传递的完整报错信息以便排查？

你好，这个就是上游newapi后台的报错，我有手动抓包了，响应体就是这样的。