【BUG】供应商类型临时熔断

[WAY29]

如图，同一个供应商有3个key，其中一个key不支持opus，但是其他2个是支持的，现在看起来如果这个不支持opus的key先被检测到不支持opus，就会临时把另外2个key都禁用了，这是不符合逻辑的

[github-actions]

Thank you for reporting this issue.

Analysis:

Based on my investigation of the codebase, I have confirmed this is a valid bug. The issue lies in the design of the VendorTypeCircuitBreaker (vendor-type circuit breaker).

Root Cause:

The vendor-type circuit breaker uses vendorId + providerType as the key (src/lib/vendor-type-circuit-breaker.ts:26-28):

function getKey(vendorId: number, providerType: ProviderType): string {
  return `${vendorId}:${providerType}`;
}

This means all providers (keys) under the same vendor and type share the same circuit breaker state. When one key triggers a circuit break (e.g., due to not supporting opus model), all other keys under the same vendor+type combination are also affected.

Trigger Condition:

In src/app/v1/_lib/proxy/forwarder.ts:960-974, when all endpoints of a provider timeout (status code 524), the vendor-type circuit breaker is triggered:

if (
  !isMcpRequest &&
  statusCode === 524 &&
  endpointCandidates.length > 0 &&
  endpointAttemptsEvaluated >= endpointCandidates.length &&
  allEndpointAttemptsTimedOut &&
  currentProvider.providerVendorId
) {
  await recordVendorTypeAllEndpointsTimeout(
    currentProvider.providerVendorId,
    currentProvider.providerType
  );
  // ...
}

Impact:

In src/app/v1/_lib/proxy/provider-selector.ts:876-888, when selecting a provider, the vendor-type circuit breaker state is checked:

if (
  p.providerVendorId &&
  p.providerVendorId > 0 &&
  (await isVendorTypeCircuitOpen(p.providerVendorId, p.providerType))
) {
  context.filteredProviders?.push({
    id: p.id,
    name: p.name,
    reason: "circuit_open",
    details: "供应商类型临时熔断",
  });
  continue;
}

This causes all providers under the same vendorId + providerType to be filtered out, even if only one key has issues.

Potential Solutions:

1. Change the circuit breaker granularity: Use providerId (individual key) instead of vendorId + providerType as the circuit breaker key
2. Add model dimension: Use vendorId + providerType + model as the key, so circuit breaks are model-specific
3. Improve trigger conditions: Only trigger vendor-type circuit break when all keys under the same vendor+type fail, not just one

Affected Files:

• src/lib/vendor-type-circuit-breaker.ts (lines 26-28) - Circuit breaker key generation
• src/app/v1/_lib/proxy/forwarder.ts (lines 960-974) - Circuit breaker trigger logic
• src/app/v1/_lib/proxy/provider-selector.ts (lines 876-888) - Provider filtering logic

---

Automated response from Claude AI

[WAY29]

另外把供应商临时熔断之后，还没办法手动恢复，在供应商页面也没有显示被熔断，只能从log里蛛丝马迹看到

[WAY29]

这个问题看起来也会影响优先级，负载均衡，fallback的问题，比如在只有一个供应商的情况下，它的渠道A坏了，另外一个渠道B是好的，此时会直接显示所有供应商不可用，而不是会去尝试渠道B，这个问题会非常影响使用，而且是在添加了新的"列表"方式管理一个供应商多key的功能之后才出现的，感觉跟这个问题是相同的 @ding113

[ding113]

收到 我研究一下