端点熔断在 UI 和决策链中的可见性不足

[Ding262]

问题描述

当前系统有三层熔断机制（provider / endpoint / vendor-type），但 UI 和决策链仅对 provider（key）级熔断有完整可见性。

端点熔断在以下方面存在盲区：

1. 服务商视图：端点表格只显示 isEnabled（DB），不显示运行时熔断状态，用户看到“启用”但实际不可用。
2. 服务商管理页：熔断筛选器和计数仅覆盖 key 熔断，服务商端点熔断情况不被筛出。
3. 决策链/时间线：endpoint-selector 静默过滤熔断端点，不记录到 ProviderChainItem，用户只看到“选择了供应商”，但不知道为何请求挂起。

影响

• 运行时状态与 UI 状态不一致，导致误判。
• 排障时缺少关键上下文，诊断成本高。
• On-call 阶段可观测性不足，影响故障处理效率。

期望

• 在服务商视图与管理页补齐 endpoint 级熔断可见性。
• 在决策链/时间线记录 endpoint 被熔断过滤的原因与证据。

[github-actions]

Thank you for this detailed feature request. I've analyzed the codebase to validate each of the three gaps you identified.

Analysis

Gap 1: Endpoint table shows only isEnabled, not runtime circuit state

Confirmed. The endpoint table in src/app/[locale]/settings/providers/_components/provider-endpoints-table.tsx (lines 279-300) renders only an enabled/disabled badge based on endpoint.isEnabled from the database. It does not fetch or display the runtime circuit breaker state.

The endpoint circuit state is available in a different place: the endpoint hover popover (src/app/[locale]/settings/providers/_components/provider-endpoint-hover.tsx, lines 104-149) fetches getEndpointCircuitInfo on hover and uses getEndpointStatusModel() to display circuit-open/half-open badges. However, this is only visible on hover and not in the main table view, so a user scanning the table would see "enabled" for an endpoint that is actually circuit-broken at runtime.

The status model logic itself (src/app/[locale]/settings/providers/_components/endpoint-status.ts, lines 43-107) already correctly prioritizes circuit state over probe status -- it just isn't wired into the table columns.

Gap 2: Circuit breaker filter/count only covers provider (key) level

Confirmed. The provider manager (src/app/[locale]/settings/providers/_components/provider-manager.tsx, lines 88-90) counts circuit-broken items using:

const circuitBrokenCount = useMemo(() => {
  return providers.filter((p) => healthStatus[p.id]?.circuitState === "open").length;
}, [providers, healthStatus]);

This only checks provider-level healthStatus, which comes from getAllHealthStatusAsync() in src/lib/circuit-breaker.ts. Endpoint-level circuit state (managed by src/lib/endpoint-circuit-breaker.ts) and vendor-type circuit state (managed by src/lib/vendor-type-circuit-breaker.ts) are not included in this count or filter.

A provider whose key-level circuit is closed but whose endpoints are all circuit-broken would not appear in the "circuit broken" filter, even though it is effectively unavailable.

Gap 3: Endpoint selector silently filters circuit-broken endpoints without recording to the decision chain

Confirmed. In src/lib/provider-endpoints/endpoint-selector.ts (lines 44-51):

const circuitResults = await Promise.all(
  filtered.map(async (endpoint) => ({
    endpoint,
    isOpen: await isEndpointCircuitOpen(endpoint.id),
  }))
);
const candidates = circuitResults.filter(({ isOpen }) => !isOpen).map(({ endpoint }) => endpoint);

Circuit-broken endpoints are silently excluded. No information about which endpoints were skipped or why is recorded anywhere.

By contrast, provider-level circuit filtering in src/app/v1/_lib/proxy/provider-selector.ts (lines 866-897) does record filtered providers with reasons into context.filteredProviders (e.g., reason: "circuit_open" with details). The ProviderChainItem.decisionContext.filteredProviders type (src/types/message.ts, lines 142-156) only has fields for provider-level filtering -- there is no analogous structure for endpoint-level filtering.

Summary of Affected Code

Gap	Primary File	Lines
Endpoint table missing circuit state	src/app/[locale]/settings/providers/_components/provider-endpoints-table.tsx	279-300
Circuit filter only covers provider level	src/app/[locale]/settings/providers/_components/provider-manager.tsx	88-90
Silent endpoint filtering in selector	src/lib/provider-endpoints/endpoint-selector.ts	44-51
Decision chain type lacks endpoint filtering	src/types/message.ts	142-156

Existing Infrastructure That Can Be Leveraged

• getEndpointCircuitInfo() action in src/actions/provider-endpoints.ts already exposes endpoint circuit state to the frontend.
• getEndpointStatusModel() in src/app/[locale]/settings/providers/_components/endpoint-status.ts already maps circuit state to UI status tokens with appropriate severity/icons.
• The ProviderChainItem.decisionContext structure in src/types/message.ts provides a pattern for how provider-level filtering is recorded, which could be extended for endpoint-level filtering.

All three gaps identified in this issue are valid and verifiable in the current codebase.

---

Automated response from Claude AI