elky
9309ad844f
test(gateway): align routing fixtures with strategy policies
2026-09-03 14:11:15 +08:00
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
4a0775c4ea
style: apply cargo fmt across gateway and aether-ai crates
2026-08-17 14:53:53 +08:00
AAEE86
6fc02dad3e
fix(ws): restore redacted PII in provider frames before client delivery
...
Responses WebSocket 只实现了脱敏的一半：请求侧 mask 之后，provider 事件帧在推给
客户端之前没有还原，于是 session 映射内的占位符以 <AETHER:EMAIL:...> 的形式直接
透给客户端。这里补齐响应侧，语义与 HTTP 路径对齐。
- 还原点是 relay loop 的最后一跳（send_client_message 之前、capture_client_frame
之前），对应 HTTP 的 restore_sync_response_body / StreamingResponseRestorer 所在
位置。审计与终态观测继续消费脱敏态事件，只有发往客户端的那一份拷贝被还原。
- 复用 privacy::restore_json_strings（改为 pub(crate)）与
RedactionSession::restore_text，不复制任何还原逻辑：只还原本 session mask 过的
映射，未映射的占位符原样保留；type / model / id 等协议字段不可能命中 sentinel，
因此不受影响。批量 {"chunks":[...]} 帧一并递归还原。
- session 生命周期：mask 仍然是 per-turn（slot 依旧每轮新建），但 session 改由连接
持有，按有界 FIFO 留最近 8 轮。理由是 WS 的会话历史留在上游，continuation 只发
增量输入，per-turn 释放会漏还原后续响应里回显的更早轮次占位符；HTTP 不会漏，是
因为它每次重发整段历史、重新 mask 会派生出同一个 sentinel。被挤出窗口的轮次退回
「占位符原样透传」，不会错误还原成别的值。
- 未命中还原时不改写字节；连接上没有任何 mask session 时（未启用脱敏）连事件 clone
都不做。
测试：redaction.rs 新增 8 条单测（还原命中/批量帧/未映射占位符原样/未命中不改写/
无 session 不介入/空 session 不留存/审计侧入参不被改写/跨轮还原/窗口有界）；
responses_websocket_e2e 新增一条用例，mock 上游回显收到的 input，断言上游只看到
占位符而客户端拿到真实邮箱。
2026-08-17 14:53:46 +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
247e7105a2
fix(ws): bill a provider-reached terminal even when client delivery fails
...
评审第 5 条后半：provider 终态已经到达、只是 gateway 写客户端 socket 失败时，
relay loop 用 client_disconnected() 覆盖了结算信号，于是一条供应商已经完成推理
并消耗了 token 的响应被记成 void billing、candidate 记 Cancelled、不投射供应商
效果、也不提交 execution report。上游成本凭空消失。
结算表只改一行：作废账单的条件从
provider.cancelled_by_provider() || delivery.is_aborted()
收紧为
provider.cancelled_by_provider() || (delivery.is_aborted() && !provider.is_terminal())
于是 Terminal{cancelled=false} + delivery Aborted 与 delivery Complete 落在同一侧：
Billed、candidate Success 或 Failed、投射供应商效果、提交 execution report。
状态码随之变成纯 provider 事实（不再把 200 改写成 499）；作废分支的 provider
状态码本身就是 499，取值不变。
依据：供应商已经完成推理并消耗 token，客户端还能用 previous_response_id 续取
这条响应。供应商没给出终态时（客户端先走了）仍然作废，这一侧未改。
配套改动：
- connection.rs 写客户端失败处改为 record_client_delivery_aborted(reason) +
settle_signal_for_client_delivery_failure(terminal_outcome)：provider 终态已到达
就用那条终态作结算信号，不再无条件覆盖。投递失败原因也不再谎称
「客户端在终态前断开」。
- 投递结果记在 attempt 上而非 logical turn 上：结算按 attempt 进行，且配额透明
重试时各 attempt 的投递结果彼此独立。
- report_context 新增 websocket_client_delivery="aborted" 与
websocket_client_delivery_reason，只增字段不改既有字段，便于事后区分
「客户端拿到了」和「客户端没拿到但已计费」。
- candidate error_type 新增 client_delivery_failed（原先这个场景写的是
websocket_cancelled）。它排在供应商侧分类之前：这条记录之所以特别正是因为
内容没送到客户端，供应商侧判定仍由 candidate_status 与 error_message 保留。
- finish_summary 改用作废判定而非「投递失败」判定：provider 终态已到达时摘要
必须保留真实的 finish_reason 与 usage，否则计费记录会被写坏。
e2e 期望值变化：client_disconnect_mid_turn_still_settles_the_usage_row 改名为
client_disconnect_before_any_provider_output_settles_a_void_row，并补上
「不计费 + status=cancelled + status_code=499」的断言。原用例的 mock 行为是
StallAfterCreated（只发 response.created 就静默），provider 从未给出终态，所以
它走的是未改动的作废一侧；原来的文档注释说「must still be billed」与实际语义
不符，一并纠正。真正被修正的那一行无法在 e2e 里确定性触发——它取决于 relay
loop 的 select! 先观察到上游终态帧还是先观察到已关闭的客户端 socket，是构造性
竞态——因此由 relay 级单测确定性覆盖，e2e 里以注释指向这两个单测。
新增 7 个测试：结算表修正行（并与「投递成功」逐字段对照，只有 candidate 错误
分类不同）、无终态时仍作废、供应商声明取消即使送达也不计费、结算信号选择、
已记录的投递失败不被结算信号覆盖、relay 级「终态到达 + 客户端已关闭 ⇒ Billed /
Success / ProviderSuccess / 已提交 report 且 usage 完整保留」及其镜像、
report_context 只增不改。
2026-08-17 14:53:12 +08:00
AAEE86
621a528083
test(ws): Responses WebSocket 端到端套件接入 CI
...
补齐 aether-integration-tests 的 responses_websocket_e2e 集成测试，
并把 CI 的 scenario 任务从 --bins 改为 --bins --tests，否则该套件
不会被执行。
2026-08-17 14:51:24 +08:00
elky
713010fa0a
fix(gateway): restore auth role refresh and Rust checks
...
Refresh the resolved user role without bypassing owner group and key policies. Resolve Rust 1.95 Clippy failures and make the pending persistence bound test scheduler-independent.
2026-07-22 11:25:24 +08:00
elky
fc92c4f431
perf(gateway): scale request hot paths for 20k streams
...
Shard and singleflight hot-path caches, batch and prioritize candidate and usage lifecycle persistence, and extend database and pressure-test instrumentation for 20k concurrent streams.
2026-07-22 02:11:08 +08:00
elky
8616fe6ee2
refactor(workspace): enforce layered crate boundaries
2026-07-15 23:47:19 +08:00
elky