[bug] 多 Key 渠道的 Key 级自动恢复不会生效

[faithleysath]

提交前必读（请勿删除本节）

• 文档：https://docs.newapi.ai/
• 使用问题先看或先问：https://deepwiki.com/QuantumNous/new-api
• 转发类问题必须先确认问题发生在 new-api 这一层；本 issue 报告的是多 Key 渠道的 Key 级自动恢复状态机问题，不把上游超时本身归因于 new-api。
• 不接受 Coding Plan、逆向渠道、第三方封装接口，以及将 Codex 接口反代为通用 API 后产生的兼容性问题：本问题与具体渠道产品无关，涉及通用的多 Key 渠道恢复逻辑。
• 本项目不提供官方托管服务，也不为第三方托管站、中转站或 API 服务提供技术支持：以下证据来自本仓库 Release 的自行部署实例，用于复现本仓库通用行为。
• 警告：删除本模板、删除小节标题或随意清空内容的 issue，可能会被直接关闭；重复恶意提交者可能会被 block。

部署来源

本仓库 Release / 官方镜像（自行部署）

您当前的 newapi 版本

v1.0.0-rc.23-nexus.3（revision：477286ebe8ff64ac31d63f858a1b03d956edf0d3）

提交确认

• 非重复 issue: 已搜索现有 Issues。现有自动恢复相关 issue 被动恢复使用非流式 Chat 探测，导致 Responses 流式渠道反复复活后超时禁用 #30、渠道测试单次成功即全量恢复，生产负载下持续超时抖动 #41 分别讨论探测协议不匹配和单次成功即全量恢复；当前没有跟踪多 Key 渠道 Key 级自动恢复缺失的问题。
• 提交前必读: 已阅读文档、项目 README 和提交要求，确认不是使用、配置或接入问题。
• 模板完整: 未删除本模板中的引导内容或小节标题。
• 受支持版本: 已提供准确版本、revision 和镜像来源。
• 非第三方服务: 问题不依赖某个托管站或具体上游，使用通用多 Key 渠道即可复现。
• 问题归属: 已区分上游超时与 new-api 行为；上游超时负责触发自动禁用，new-api 的问题是之后无法对被禁用 Key 做恢复探测。
• 维护成本: 已提供脱敏、可量化、可复现的证据和明确修复方向。

问题描述

实际现象

当前 passive_recovery 是渠道级调度，但多 Key 渠道的禁用状态可以细化到 key_index。当某一把 Key 因真实请求失败而自动禁用时：

1. 如果同一渠道仍有其他启用 Key，渠道整体保持启用。
2. 被禁用的 Key 不会被恢复任务单独探测，因此会一直保持自动禁用。
3. 如果所有 Key 都被自动禁用，渠道整体进入 auto-disabled；恢复任务虽然会选中该渠道，但测试无法选择任何已禁用 Key，通常在本地快速失败，不会真正请求上游。

这使多 Key 渠道的 Key 级自动恢复没有有效路径。单 Key 渠道不存在这个问题，因为渠道和 Key 是同一个恢复对象。

脱敏生产证据

实时配置：

monitor_setting.auto_test_channel_enabled=true
monitor_setting.auto_test_channel_minutes=3
monitor_setting.channel_test_mode=passive_recovery
AutomaticEnableChannelEnabled=true
AutomaticDisableChannelEnabled=true

一个两 Key 轮询渠道的状态如下：

channel_info.is_multi_key=true
channel_info.multi_key_size=2
channel_info.multi_key_status_list={0: auto-disabled, 1: auto-disabled}
channel.status=auto-disabled
channel.other_info.status_reason_code=all_keys_disabled

该渠道最近一次自动禁用事件来自首响应超时窗口：

key_index=1: first response timeout rate 36.36% (4/11 attempts in 5 minutes)
key_index=0: first response timeout rate 41.67% (5/12 attempts in 5 minutes)
channel: all_keys_disabled

之后定时任务仍持续运行。最近一轮任务摘要为：

channel_test: tested=3, succeeded=0, failed=3

目标渠道的 test_time 被更新，但测试耗时约 3 ms，应用日志没有对应的上游测试请求，说明它在本地因没有可用 Key 结束，而不是完成了恢复探测。

与现有 issue 的边界

• 被动恢复使用非流式 Chat 探测，导致 Responses 流式渠道反复复活后超时禁用 #30 讨论被动恢复的探测协议与生产流量不一致；本 issue 讨论的是多 Key 渠道的 Key 选择与恢复对象不一致。
• 渠道测试单次成功即全量恢复，生产负载下持续超时抖动 #41 讨论单次合成探测成功后直接恢复整条渠道；本 issue 即使不改变恢复成功判据，也要求先解决被禁用 Key 根本无法被探测的问题。
• 本 issue 不依赖某个具体上游、模型、协议或中转站配置；任意开启自动禁用、自动恢复和多 Key 轮询的渠道都可能复现。

复现步骤

1. 创建一个启用自动禁用和自动恢复的多 Key 渠道，配置两把 Key 并启用轮询模式。
2. 让 Key A 的真实请求触发自动禁用，但保持 Key B 启用。
3. 等待多轮被动恢复任务，观察 Key A 的状态；渠道仍可用，但 Key A 不会被单独探测或自动恢复。
4. 再让 Key B 也触发自动禁用，使渠道整体进入 auto-disabled。
5. 等待下一轮被动恢复任务。
6. 观察任务会统计该渠道，但测试没有使用 Key A 或 Key B 向上游发送请求，渠道仍保持自动禁用。

预期结果

自动恢复应区分渠道级状态和 Key 级状态：

• 对仍有启用 Key 的多 Key 渠道，恢复任务应按 key_index 针对自动禁用 Key 发起受控的半开探测；成功后只恢复该 Key，不影响其他 Key。
• 对所有 Key 都禁用的渠道，恢复任务应逐把选择自动禁用 Key 进行探测；不能因为渠道没有当前启用 Key 就在本地快速失败。
• 手动禁用的 Key 不应被自动恢复。
• Key 级恢复成功、失败和竞争覆盖都应写入带 key_index 的状态事件，并使用条件更新避免把后续手动禁用或新失败覆盖掉。
• 渠道整体只有在至少一把 Key 恢复成功后才应重新进入可路由状态。

一种可行的实现方向是：让被动恢复任务枚举 key_index 级状态，使用目标 Key 执行测试，并让测试/路由上下文显式携带目标 Key，而不是通过当前渠道级轮询选择器间接取 Key。恢复测试仍可复用现有协议匹配、首响应事件和自动禁用判据。

相关截图

无。证据来自脱敏后的管理 API、PostgreSQL 状态事件、系统任务摘要和应用日志，不包含渠道密钥、用户令牌、请求正文或上游账号信息。