[Feature] 供应商级别可配置：故障转移恢复后是否强制切回高优先级供应商

[Mriris]

场景描述

设置了两个供应商：

• 供应商 A：优先级 0（便宜但不稳定的渠道）
• 供应商 B：优先级 1（稳定但昂贵的渠道）

当供应商 A 连接失败后，系统正确地 failover 到供应商 B。但当供应商 A 恢复正常后，由于 session 的 sticky binding 机制，同一会话内后续请求仍然走供应商 B，持续产生高额费用。

对于 Claude Code 这种长会话场景，会话可能持续数十分钟甚至数小时（每次请求都会刷新 TTL），一旦 failover 到贵渠道，整个会话期间都无法切回便宜渠道。

为什么不能改为全局默认行为

当前的 sticky binding 设计对很多用户是合理的：

• 同倍率的多渠道场景，保持绑定可以最大化缓存命中率，减少不必要的供应商切换
• 频繁切换供应商会导致上下文缓存失效，反而增加成本

只有渠道间价格差异大的场景才需要尽快切回高优先级供应商。

期望行为

在供应商设置中增加一个独立的开关/选项（例如"故障恢复后强制切回"或"始终优先选择"），启用后：

• 当该供应商从熔断状态恢复时，即使当前会话已绑定到其他健康供应商，也无条件将绑定迁移回该供应商
• 未启用此选项的供应商保持现有行为（保持当前绑定，最大化缓存命中）

当前代码行为参考

src/lib/session-manager.ts 的 updateSessionBindingSmart 函数中，故障转移后的绑定更新逻辑：

场景	当前决策
故障转移成功	无条件更新绑定到备用供应商
原供应商恢复，当前绑定仍健康	保持当前绑定（keep_healthy_higher_priority）

建议在第二种场景中，检查原供应商是否开启了"强制切回"选项，如果是则执行迁移。

建议的实现方向

1. 在供应商配置中增加一个布尔字段（如 alwaysPreferred / forceRecovery）
2. 在 updateSessionBindingSmart 或 findReusable 中，当检测到有开启此选项的更高优先级供应商已恢复健康时，清除当前绑定并切回
3. UI 上在供应商设置中增加对应的开关

[coderabbitai]

🔗 Related PRs

#556 - feat: 添加供应商缓存开关配置, 默认启用 [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 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!

[ding113]

您好，后续会计划给单独的供应商增加一个“是否允许会话复用”的配置，应当能够满足这一需求。敬请期待后续发版计划。

[github-actions]

Thank you for this well-documented feature request.

Analysis:

Based on my analysis of the codebase, your understanding of the current behavior is accurate. The relevant code is in:

1. src/lib/session-manager.ts (lines 636-837) - updateSessionBindingSmart function:

The function handles session binding updates with these scenarios:

• Failover success (lines 685-700): Unconditionally updates binding to the backup provider
• Current provider healthy with higher/equal priority (lines 816-830): Keeps the current binding with reason keep_healthy_higher_priority

The key decision point is at lines 791-830, where if the new provider has lower or equal priority, the system checks if the current provider's circuit is open. If the current provider is healthy (circuit closed), the binding is preserved.

2. src/app/v1/_lib/proxy/provider-selector.ts (lines 517-654) - findReusable function:

This function handles session-based provider reuse. It checks:

• Provider availability (isEnabled)
• Active time window (activeTimeStart/activeTimeEnd)
• Circuit breaker state (both provider-level and vendor-type level)
• Model support
• Client restrictions
• User group permissions

Feasibility assessment:

This feature is architecturally feasible. The implementation would involve:

1. Schema changes:

• Add a new boolean field to the providers table (e.g., forceRecovery or alwaysPreferred)
• Update src/drizzle/schema.ts (providers table, around line 159)
• Update src/types/provider.ts (Provider interface, around line 281)

2. Logic changes in src/lib/session-manager.ts:

• Modify the updateSessionBindingSmart function to check if the higher-priority provider has forceRecovery: true
• This would add a new condition before the keep_healthy_higher_priority return (around line 816)

3. Logic changes in src/app/v1/_lib/proxy/provider-selector.ts:

• Potentially modify findReusable to detect if a higher-priority provider with forceRecovery: true has recovered
• This would allow proactive switching even during session reuse

Implementation considerations:

• The feature needs to handle the race condition where multiple concurrent requests might try to switch simultaneously
• Need to ensure the recovered provider's circuit is fully closed (not half-open) before forcing the switch
• Should consider adding a cooldown period to prevent flapping between providers
• UI changes needed in the provider settings form

Dependencies:

• Database migration workflow (as documented in CLAUDE.md)
• i18n support for 5 languages
• Unit test coverage for the new logic

---

Automated response from Claude AI

[Mriris]

佬友你好，感谢回复！

不过我仔细想了一下，"是否允许会话复用"和我描述的场景可能还是有些差异，担心粒度太粗会带来副作用，想补充说明一下：

如果对贵渠道（供应商 B）禁用会话复用，那么 failover 到 B 之后，B 的每次请求都不会复用会话，也就彻底丧失了 B 上的上下文缓存。在便宜渠道（供应商 A）因不稳定转移后，请求会落到 B 且每次都没有缓存，token 成本反而可能比现在更高。

我理想中的行为其实是：

1. A 正常时：绑定 A，正常享受缓存
2. A 故障，failover 到 B 时：绑定 B，B 上也正常积累缓存（会话复用仍然生效）
3. A 恢复时：下一个请求检测到 A 已恢复且优先级更高，仅此时切换一次回 A

也就是说，关键点不是"B 不允许复用"，而是"A 恢复后主动抢回绑定"。两者的区别在于：

方案	failover 期间 B 的缓存	A 恢复后的切换
禁用 B 的会话复用	无缓存（每次重选）	能切回，但过程中一直没缓存
供应商级"恢复后强制切回"开关	B 正常缓存	A 恢复后才切换一次，之前 B 上的缓存没浪费

再次感谢佬友的开发和维护！

[ding113]

佬友你好，感谢回复！

不过我仔细想了一下，"是否允许会话复用"和我描述的场景可能还是有些差异，担心粒度太粗会带来副作用，想补充说明一下：

如果对贵渠道（供应商 B）禁用会话复用，那么 failover 到 B 之后，B 的每次请求都不会复用会话，也就彻底丧失了 B 上的上下文缓存。在便宜渠道（供应商 A）持续不稳定、反复故障的场景下，请求会频繁落到 B 且每次都没有缓存，token 成本反而可能比现在更高。

我理想中的行为其实是：

1. A 正常时：绑定 A，正常享受缓存
2. A 故障，failover 到 B 时：绑定 B，B 上也正常积累缓存（会话复用仍然生效）
3. A 恢复时：下一个请求检测到 A 已恢复且优先级更高，仅此时切换一次回 A

也就是说，关键点不是"B 不允许复用"，而是"A 恢复后主动抢回绑定"。两者的区别在于：

方案 failover 期间 B 的缓存 A 恢复后的切换
禁用 B 的会话复用 无缓存（每次重选） 能切回，但过程中一直没缓存
供应商级"恢复后强制切回"开关 B 正常缓存 A 恢复后才切换一次，之前 B 上的缓存没浪费
所以我想请教一下，后续的"会话复用配置"是否也会覆盖到这种"恢复后主动迁移"的场景？如果暂时不在计划内的话，是否可以考虑增加一个类似 forceRecovery 的独立开关？

再次感谢佬友的开发和维护！

假设 A 持续不稳定，每一次都 fallback 到 B，哪怕 B 在 CCH 内不是因为会话复用而被选择的，依然可以命中缓存。因为缓存是推理侧的特性，只要相同对话流向了相同渠道，就能命中缓存。
在 B 不允许会话复用的前提下，每一次请求都会触发决策链，故而先尝试 A（因为优先级更高），若 A 可用则用 A，若 A 不可用则用 B，这应当符合您的场景。