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

• 文档：https://docs.newapi.ai/
• 使用问题先看或先问：https://deepwiki.com/QuantumNous/new-api
• 警告：删除本模板、删除小节标题或随意清空内容的 issue，可能会被直接关闭；重复恶意提交者可能会被 block。

您当前的 newapi 版本

v0.11.9-alpha.1

提交确认

• 我已确认目前没有类似 issue
• 我已完整查看过文档 https://docs.newapi.ai/ 和项目 README，尤其是常见问题部分
• 我未删除此模板中的任何引导内容或小节标题，并会按要求完整填写
• 我理解项目维护者精力有限，不遵循模板要求的 issue 可能会被无视或直接关闭

问题描述

在 v0.11.9-alpha.1 下，如果默认的 codex cli trace / claude cli channel affinity 缓存命中了一个已经失效的渠道，当前请求不会继续走正常的渠道选择，而是直接被这个 stale affinity 卡死。

我这边的实际表现是：Codex CLI 会连续出现 429 Too Many Requests、exceeded retry limit，但同一模型、同一分组下其实还有其他健康渠道可以正常返回 200。删除对应的 Redis affinity key 后，同一线程立刻恢复。

我排查后发现这个现象与提交 5fe8e98eeba283938c84d8952935b706eb74a045 高度相关。这个提交把默认 Codex / Claude affinity 规则的 SkipRetryOnFailure 改成了 true。对于“真实的上游失败”这没有问题，但对于“缓存里的 affinity 已经指向失效渠道”这个场景，当前逻辑会过早终止正常 fallback。

现网证据：

• 版本：v0.11.9-alpha.1
• 示例 stale affinity key：new-api:channel_affinity:v1:codex cli trace:default:019d1b41-a32c-7840-92cd-fa6f39fd5f59 = 42
• 渠道 42 持续返回 403 用户额度不足 和 429
• 同时其他可用渠道（例如 33、43）仍能返回 200
• 手动删除该 Redis key 后，故障线程恢复

对应修复 PR：#3413

复现步骤

1. 使用启用了 channel affinity 的 new-api v0.11.9-alpha.1。
2. 让 Codex CLI 或 Claude CLI 请求先创建一条 affinity 缓存，键类似 new-api:channel_affinity:v1:codex cli trace:default:*。
3. 将该 affinity 指向的首选渠道置为 disabled，或者让它不再满足当前 group / model 的可用条件。
4. 使用相同的 affinity key 再发起请求。

预期结果

当 affinity 缓存指向的渠道已经失效、缺失或不再匹配当前 group / model 时，应该先清理或忽略这条 stale affinity，然后继续走正常的渠道选择流程。

SkipRetryOnFailure 应该只影响“首选 affinity 渠道已成功选中，但真实上游请求失败”的场景，不应该让 stale affinity 直接阻断 fallback。

相关截图

暂无界面截图；可稳定复现的证据是上述 Redis key、渠道状态与请求日志。PR #3413 中已附本地测试结果。