Repository navigation
fix(accounts): recognize streamed credit balance exhaustion - #8141
Conversation
Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; reasoning_effort=max
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
动机 / Motivation
使用已配置 API 池的原管家,以及查看 Key 状态的用户。 HTTP 200 流里出现明确余额耗尽时,旧版仍将该 Key 留作 accepted;修复后记录额度耗尽,当前流不重放,后续独立请求选择其他可用 Key。 余额耗尽的真实错误事件不再被当成后续请求仍可用的 Key。 本次不查询账单余额、不增补资金、不扩大 API 使用许可,也不增加业务重放。 原会话实际额度失败已读回,但其原始流错误码尚未取得;所有历史问题的正常补回复仍须逐条验证。
改动思路 / Approach
只在现有共享 TypeScript 错误分类中补一个官方明确代码,继续复用原 HTTP/SSE 反馈、私有 Key owner 和正式 provider 生命周期。 交付已复现的错误分类修复及可安装版本;真实账户可用容量与原消息结果送达继续独立验收。
这不是增加一个兜底执行器。原请求仍由既有 relay 发送,结构化流式错误通过 apiStreamOutcome 进入同一 apiOutcome,最后由既有私有 Key owner 记录状态。补充的是官方明确的余额耗尽错误码;状态、冷却、Key 顺序及消息业务权威继续沿用。与不修改相比,它能防止已明确失败的 Key 被持续记录成 accepted;与正文关键词匹配相比,它不会把用户引用的错误说明当作真实额度事实。
具体改动 / Changes
既有规范:packages/loopx-codex-provider-routing/NATIVE.md,版本 9269f49d0c62d5957753277e7f720df8ad394a95;独立核对官方 API 错误码中 credit_balance_exhausted。Native-explicit-quota 已落实到共享列表及两种实际 HTTP 流事件;Native-started-stream 通过原流字节、单次上游调用及下一次独立请求断言核验;Native-existing-policy 保留原私有 Key owner、订阅优先和 API 准入条件。规范增补不能代替真实账户余额证明。
7 文件 +19/-5,生产语义仅共享列表多一个值,其余为测试、文档及三个版本元数据。没有新协议、任务、消费者或存储。HTTP 429 使用该码时,从原通用限流状态转为 quota_exhausted;没有 Retry-After 时沿用既有额度冷却 300 秒,该差别已明确写进文档和断言。
关键代码讲解
apiStreamOutcome仍要求 type=error 的 code,或 response.failed 中 status=failed 的 error.code。共享列表增加信用余额耗尽后返回既有 429 结果,供原 observer 更新后续 Key 可用性。模型文本、空码、未知码、截断 JSON 和错误响应状态仍不匹配。apiOutcome同样读取该列表。HTTP 路径现在采用既有硬额度分类及冷却,保留 Retry-After、选定模型与权限范围。原有网络未知效果和已开始流不尝试第二把 Key;后续独立请求才读取新的候选状态。
对主干的风险 / Risks
主要风险是误分类扩大到普通失败,或把下一次选 Key 误做当前流重放。测试覆盖两种 credit 事件和同一个真实 HTTP relay:原始字节完全相同,上游当前只调用一次,下一次请求保持原模型和 body 并选择另一个 Key。原文引用错误码、仅有错误说明、未知错误、畸形或截断事件、网络中断及默认关闭的准入负例继续保留。
PASS:42 项相关 Python 测试及 3 项 TS 测试;最终增加的 HTTP 冷却断言已独立重跑。配对基线为精确 948d25e 的生产源码、同一测试文件:2 个 credit 变体失败为 accepted 与 quota_exhausted 不符,8 个既有控制通过。当前版本全部通过。源 checkout premerge 通过,使用明确安装的 TypeScript compiler 和 Node types 完成类型检查;最初 npx 命中了无关缓存命令及随后缺 Node types 的检查均未被当作通过。按 Goal 配置不查询 CI。
语义与 CI 对齐
只扩充现有 provider 的上游错误词汇,复用 quota_exhausted 及原冷却,没有新增通用 Goal、调度或结算义务。安装/就绪不激活付费使用,角色、令牌、Origin 和未启用路径沿用原门禁;当前真实 HTTP 与 API 回归覆盖了这些边界。版本 0.15.2 使用既有正式 provider 生命周期安装,回滚保留 0.15.1 环境;不重放原消息或更改真实失败历史。
我的整体评价 / Verdict
本次为 justified_increment / APPROVE,long_horizon 和 user_experience 均改善:明确信用耗尽能反映到未来候选,减少同一不可用 Key 的失败循环,用户无需再次输入既有意图或授权。只在现有共享 TypeScript 错误分类中补一个官方明确代码,继续复用原 HTTP/SSE 反馈、私有 Key owner 和正式 provider 生命周期。 交付已复现的错误分类修复及可安装版本;真实账户可用容量与原消息结果送达继续独立验收。
一行共享规则配合两种原生流反证,比另造分类器或重试器更合适。原 Key 顺序与未知错误边界保留;对 HTTP 冷却差别也没有声称完全等价。无渲染界面改动,视觉验收不适用。线上原生额度失败已经读回,但原始流码和业务补回复尚未完整核验,所以不会把官方缺失码修复说成全部现场故障的唯一根因或全部历史消息完成。
English verdict: APPROVE the bounded shared credit-error classification fix; live original replies remain separately unverified.
原生管家持续报额度不足,而 Key 仍显示 accepted。核对官方错误码发现
credit_balance_exhausted尚未进入现有共享分类;该流式错误会被原样转发但不更新后续候选。本次把这个明确额度错误加入已有 TypeScript 策略,不增加重试器或正文匹配。已开始的流仍只转发一次;下一次独立请求跳过冷却的 Key。HTTP 429 同码沿用额度冷却,文档披露其与原通用限流冷却的差别。包版本升级为 0.15.2,使用刚合入的正式 provider 生命周期安装采用。
验证:真实 HTTP 配对反证在旧版得到 2 个预期失败、8 个控制通过;修复后 42 项相关 Python 测试及 3 项 TypeScript 测试通过。原生会话实际报额度不足已读回,但尚未取得其原始流错误码,所以不把本次缺失码修复冒称为所有线上失败的唯一根因;原消息补回复继续独立验收。