openteam

112 Commits 2 Branches 0 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
Sakurasan	531a03c836	perf: 流式错误判定预过滤、再减一个写索引，加可选明细保留期 - 流式放行前的上游错误判定加廉价子串预过滤（"error" / response.failed）：长思考阶段几十上百条事件不再逐条 json.Unmarshal。 - usage_logs 去掉 idx_channel_created：没有任何查询按 channel_id 过滤该表（渠道统计走 created_at 时间窗后在内存分组），复合索引只是每行一次多余的 B-tree 插入；schema v9 迁移里显式 DROP 旧库索引。至此该表只剩 (user_id, created_at)、created_at 两个真被用到的索引。 - 新增可选保留期（OT_USAGE_RETENTION_DAYS，默认 0=永久保留）：每天分批（2000 行/批、批间 50ms）清理过期 usage_logs，避免长期运行后时间窗查询与备份随表增长变慢；余额流水 balance_logs 不在清理范围。参数复测（记账稳态吞吐，3 次取中位）： - batch 64（当前）30.2k rows/s；batch 128 19.0k、batch 256 14.3k（更差，保持 64） - wal_autocheckpoint(4000)、cache_size(-64MB) 与当前配置无差别，不引入验证：go vet、go test ./...、-race（usage/proxy/store）全绿；新增保留期三项测试（只删明细不动流水、未开启不动数据、跨分批删完）。	2026-10-30 16:45:57 +08:00
Sakurasan	979973ddde	feat: 流式首包缓冲容错（hold）与失败分类冷却流式请求在首个内容事件到达前由网关缓冲（借鉴 magpie 的 holdWriter）：上游的错误事件、空流、断连、协议形态不符（要流给了整包）都在放行前换渠道消化，客户端无感知。扣住期间照常发 SSE 注释心跳；缓冲超过 1MB 直接放行退化为普通转发，判定失效不吞正文。 - 新增 proxy/hold.go：streamHold（缓冲/放行/心跳/首 token 计时与放行互斥）、 sseEventHasContent（chat/messages/responses 三种协议的内容判定）、 sseUpstreamError（200+流式形式的错误事件识别）、classifyUpstreamError + quotaSignals（余额/配额特征识别） - 非流式改为先读完整响应再写头：读失败（网络错误/超时）发生在写出之前，可换渠道重试；此前先写 200 头再读，超时只能给客户端留一个 200 空响应 - 协议形态校验：要流却给了整包（didNotStream）按失败换渠道，反复如此的渠道会被健康计数剔除 - 记账：每次尝试独立 trySink，只有成功走到 EOF 才并入请求级 sink——失败渠道的 message_start 用量不计入账单 - 冷却按原因分类（channel.FailKind）：余额/配额类第一次失败即冷却 30 分钟（429 不一定是限流，智谱 429「余额不足」也在此列）；其余按连续进冷却次数指数退避 30s→60s→120s，封顶 10 分钟；短于退避值的 Retry-After 不再缩短冷却 - 新增 OT_PROXY_FIRST_TOKEN_WAIT（默认 0=不限）：放行前等内容的最长时间，超时即取消本次尝试换下一个渠道 - 渠道列表接口返回 cooldown_reason，后台可区分「限流」与「余额耗尽」 - 测试：hold 缓冲/放行/心跳、内容与错误事件判定、失败分类与指数退避、容量热生效 - docs/magpie-plugin-mechanism.md：参考实现的插件机制调研	2026-10-30 02:43:23 +08:00

Author

SHA1

Message

Date

Sakurasan

531a03c836

perf: 流式错误判定预过滤、再减一个写索引，加可选明细保留期

- 流式放行前的上游错误判定加廉价子串预过滤（"error" / response.failed）：
  长思考阶段几十上百条事件不再逐条 json.Unmarshal。
- usage_logs 去掉 idx_channel_created：没有任何查询按 channel_id 过滤该表
  （渠道统计走 created_at 时间窗后在内存分组），复合索引只是每行一次多余的
  B-tree 插入；schema v9 迁移里显式 DROP 旧库索引。至此该表只剩
  (user_id, created_at)、created_at 两个真被用到的索引。
- 新增可选保留期（OT_USAGE_RETENTION_DAYS，默认 0=永久保留）：每天分批
  （2000 行/批、批间 50ms）清理过期 usage_logs，避免长期运行后时间窗查询
  与备份随表增长变慢；余额流水 balance_logs 不在清理范围。

参数复测（记账稳态吞吐，3 次取中位）：
- batch 64（当前）30.2k rows/s；batch 128 19.0k、batch 256 14.3k（更差，保持 64）
- wal_autocheckpoint(4000)、cache_size(-64MB) 与当前配置无差别，不引入

验证：go vet、go test ./...、-race（usage/proxy/store）全绿；新增保留期三项测试
（只删明细不动流水、未开启不动数据、跨分批删完）。

2026-10-30 16:45:57 +08:00

Sakurasan

979973ddde

feat: 流式首包缓冲容错（hold）与失败分类冷却

流式请求在首个内容事件到达前由网关缓冲（借鉴 magpie 的 holdWriter）：上游的错误
事件、空流、断连、协议形态不符（要流给了整包）都在放行前换渠道消化，客户端无感知。
扣住期间照常发 SSE 注释心跳；缓冲超过 1MB 直接放行退化为普通转发，判定失效不吞正文。

- 新增 proxy/hold.go：streamHold（缓冲/放行/心跳/首 token 计时与放行互斥）、
  sseEventHasContent（chat/messages/responses 三种协议的内容判定）、
  sseUpstreamError（200+流式形式的错误事件识别）、classifyUpstreamError +
  quotaSignals（余额/配额特征识别）
- 非流式改为先读完整响应再写头：读失败（网络错误/超时）发生在写出之前，可换渠道
  重试；此前先写 200 头再读，超时只能给客户端留一个 200 空响应
- 协议形态校验：要流却给了整包（didNotStream）按失败换渠道，反复如此的渠道会被
  健康计数剔除
- 记账：每次尝试独立 trySink，只有成功走到 EOF 才并入请求级 sink——失败渠道的
  message_start 用量不计入账单
- 冷却按原因分类（channel.FailKind）：余额/配额类第一次失败即冷却 30 分钟（429 不
  一定是限流，智谱 429「余额不足」也在此列）；其余按连续进冷却次数指数退避
  30s→60s→120s，封顶 10 分钟；短于退避值的 Retry-After 不再缩短冷却
- 新增 OT_PROXY_FIRST_TOKEN_WAIT（默认 0=不限）：放行前等内容的最长时间，超时即
  取消本次尝试换下一个渠道
- 渠道列表接口返回 cooldown_reason，后台可区分「限流」与「余额耗尽」
- 测试：hold 缓冲/放行/心跳、内容与错误事件判定、失败分类与指数退避、容量热生效
- docs/magpie-plugin-mechanism.md：参考实现的插件机制调研

2026-10-30 02:43:23 +08:00