mirror of
https://github.com/fawney19/Aether.git
synced 2026-09-10 13:10:21 +08:00
AAEE86
dbf2809bd6
评审第 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 凭证。