ZheFox
c8118edf36
fix(ws): harden Responses connection lifecycle
...
Revalidate control policy per turn, isolate downstream credentials, and make planner/turn ownership cancellation-safe.
Preserve opaque protocol events, align configurable timeout semantics, and extend end-to-end security and settlement coverage.
2026-08-17 18:50:29 +08:00
AAEE86
dbf2809bd6
fix(ws): settle the previous attempt before transparent retry replanning
...
评审第 2 条。配额透明重试原来的顺序是「detach 旧 attempt → 规划并绑定新
attempt → 把旧 attempt 的结算排进队列」。规划因此读到的是旧 attempt 还没投射的
health / adaptive / pool 状态，而且旧 attempt 仍占着自己的 pool key lease——替代
key 的挑选看到的是一把仍被占用的 key，最坏情况下判成「无可用供应商」而放弃一次
本可以成功的重试。
普通的新 turn 早就挡住了这件事：client.rs 在处理 response.create 前调用
await_pending_turn_finalization，注释写的正是「不要让新 turn 基于陈旧的 health /
adaptive / pool 状态规划」。透明重试是同一个问题的另一条入口，漏了这一步。
现在顺序是：detach → 释放准入 → 结算旧 attempt 并等它落地 → 规划/绑定新 attempt。
新增 lifecycle::settle_turn_finalization：与 queue_turn_finalization 的区别只在于
「等」。后者把 handle 挂在连接上让 relay loop 继续跑，用在结算之后不再读取共享
状态的出口；前者用在必须先看到结算结果才能继续的路径上。
顺序用类型固定，而不是靠注释：settle_turn_finalization 返回
PreviousAttemptSettled，retry_active_turn_after_quota_exhaustion 要求这个参数。
凭证只能由 lifecycle 颁发（结算完成，或明确「没有 attempt 要结算」），所以把顺序
写反连编译都过不了。
重试失败路径随之变化：旧 attempt 已经结算，不再 resume 回去。logical turn 仍停在
Replanning，后续分支的 end() / finalize_active_turn 只清 logical turn、不交出
attempt，因此不存在重复结算。结算 outcome 取值不变（两条路径用的都是
terminal_outcome.unwrap_or_else(upstream_closed)，而这条分支里 terminal_outcome
必为 Some——usage_limit_error 成立意味着有一个已解析的 error 终态帧）。
代价（都落在「重试失败」这一侧，且只影响已终态 attempt 的报告注解，不影响计费）：
- 那条最终转发给客户端的 429 事件不再进旧 attempt 的 client capture；
provider 侧 capture 早在 observe_upstream_frame 里就记下了。
- 如果转发 429 给客户端也失败，record_client_delivery_aborted 落在一个已经结算的
attempt 上，成为 no-op。
测试：
- lifecycle：await_turn_finalization_handle 必须「等到落地」而不是「排进队列」
（C6 依赖的性质）；结算完成后规划才读状态的顺序型断言（计数器替身）；结算任务
panic 也必须放行调用方，不能卡死 relay loop。
- turn_state：Replanning 状态下 end() 不再交出第二个 attempt（无重复结算）。
- e2e 新增 provider_quota_exhaustion_transparently_retries_onto_another_key：
mock 上游首轮只回 Codex 的 429 usage_limit_reached，网关换到第二把 key 重放同一个
response.create；断言客户端看不到 429、上游被连两次、两次用的不是同一把 key、两个
attempt 各留一条终态行（429 的那条 + 计费的那条）。已验证它在改动前后都通过——
它覆盖的是整条路径可用，顺序由上面的单测确定性覆盖。
夹具随之参数化出 ProviderFixture::CodexKeyPair：透明重试只有 Codex adapter 会
开启，而 codex 候选要求 auth_type = oauth，所以这个夹具用未过期的 oauth 凭证。
2026-08-17 14:53:40 +08:00
AAEE86
dc3743aecf
refactor(ws): 拆分 LogicalTurn 与 ProviderAttempt，结算改表驱动
...
评审第 5 条：一个 ResponsesWebSocketTurn 同时代表 logical turn 和 provider
attempt，finalize() 又用 outcome.cancelled() 一个布尔驱动 billing、candidate
状态和供应商效果，于是 provider 终态已经到达、只是最后一跳写客户端失败时，
供应商事实会被 Cancelled 覆盖掉。
- ResponsesWebSocketTurn → ResponsesProviderAttempt，
ActiveResponsesWebSocketTurn → ActiveProviderAttempt：类型名字明确它只代表
一次上游执行，logical turn 由 C1 落地的 LogicalTurn 承担。
- 新增 settlement.rs：AttemptProviderOutcome × AttemptClientDelivery 两个正交
事实，classify_attempt_settlement 一张表推出 status_code / billing /
candidate 状态 / candidate 错误分类 / 供应商效果 / 是否提交 execution report。
- attempt 观察到 provider 终态即记录 provider_outcome。结算信号
ResponsesWebSocketTurnOutcome 只回答「为什么现在结算」：ProviderTerminal 与
Failure 对 provider 是权威的，Cancelled 只描述客户端/连接层面的停止，不再
覆盖已观察到的 provider 事实。
- candidate 状态与 candidate 错误分类分开输出：现状存在
「missing_terminal=true 而记账层判 Success」的组合（report kind 不要求观察到
终态事件时），会写出 status=Success + error_type=stream_missing_terminal_event，
这个组合必须原样保留。
classify_responses_websocket_turn_effect 的判定表原样搬入 settlement.rs，分支
和顺序均未改动，两个既有不变量测试随之迁移。
行为等价。结算表当前口径与拆分前完全一致：客户端投递失败仍与「供应商声明取消」
落在同一侧（作废账单、candidate 记 Cancelled、只释放 lease、不提交 execution
report），即使 provider 终态已经到达——这一行由
settlement_table_row_client_delivery_failure_currently_voids_a_reached_terminal
锁住现状，修正它是下一步独立的行为修正。
新增 15 个测试：outcome → 双事实映射表逐行（含 stream_timeout 只在 504 失败一族
成立、provider 终态即使 504 也不投射流式超时）、结算表逐行、投递失败时
forced_error 必须为 None、已观察终态不被 Cancelled 覆盖、以及跨整张表的
「每个分支都释放 pool key lease」「作废账单一律不提交 report」不变量。
2026-08-17 14:53:05 +08:00
AAEE86
1c5ee5228c
refactor(ws): 用 ResponsesTurnState 收敛连接 turn 状态
...
评审第 2 条：BoundResponsesConnection 用 response_in_flight、active_turn、
active_response_create 三个可独立变化的字段编码同一件事，8 种组合里只有 3 种
合法，非法组合只能靠调用点的 if 和「记得同时改另外两个字段」来避免。
三字段合并为一个 ResponsesTurnState：
Idle 没有进行中的 logical turn
Responding { logical, attempt } logical 与 attempt 必须同时存在
Replanning { logical } attempt 已取走去结算/重绑，logical 仍在
Replanning 不是新概念：配额透明重试期间现状就处于这个状态，只是靠
Option::take 意外得到。转换只能走 begin / detach_attempt / resume / end，
response_in_flight 与「是否接受新 response.create」都由变体推导。
由此消除的运行时不变量（原来全靠调用点自觉）：
- 有 attempt 必有 logical turn
- response_in_flight 与 attempt 同生共死（原来 client 写失败后
active_turn=None 而 response_in_flight 仍为 true）
- logical turn 结束时必须清 attempt：原来 `active_response_create = None`
在 connection.rs 里手写 13 处，漏一处就残留；现在只有 end() 一个出口
- 上游绑定返回的连接不再自带 response_in_flight=true 的半成品状态
同时删除 update_response_in_flight：Started 帧把已经是 true 的字段再设一次，
Close 帧因为没有解析出的 frame 而根本不触发，是纯冗余写；它在 Idle 态收到
Started 帧时还会把 response_in_flight 置真，从而永久阻塞后续 response.create。
行为等价。ActiveResponsesWebSocketRequest 改名 LogicalTurn 并随状态机移入
新的 turn_state.rs；状态机对 attempt 类型泛型化，测试用轻量替身驱动同一套
转换逻辑，无需 AppState 或真实 socket。
2026-08-17 14:52:57 +08:00
AAEE86
71b54070e8
feat(gateway): Codex/OpenAI Responses WebSocket 代理模式
...
在 /v1/responses 上支持 WebSocket 升级，把客户端帧中继到上游 Codex /
OpenAI Responses WebSocket 端点，同时保持既有的路由、鉴权、配额与用量
语义：
- 路由与准入：control/route/ai.rs 识别 WebSocket 升级请求；
websocket/ingress.rs 复用 API Key 鉴权、IP 规则与并发许可，并引入
独立的 WebSocket 连接许可
- 中继：websocket/responses/* 按 connection / session / turn 分层，
帧解析归一化、socket 写入有界、continuation 保持调度亲和性
- 配额：orchestration/codex_quota_breaker.rs 在账号配额耗尽时熔断并
自动恢复，不再直接断开客户端连接
- 用量：每个 turn 的终态用量落库，request_metadata 记录
websocket_mode / websocket_transport，管理端与 usage 视图暴露
is_websocket
- 管理端：provider 可配置 Responses WebSocket 开关
2026-08-17 14:50:33 +08:00
ZheFox