Repository navigation
Reuse verified spend receipts in combined settlement - #8405
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
组合 refresh 和 spend 已拿到子进程的权威回执,却再读一次相同结算链。用同一已准入的 Todo 对照普通 writeback、首次组合结算和原 Turn 重试。新提交只在新扣额的完整证明吻合时省一次读回,最终仍给出原来的三份回执。这是隔离的真实 CLI、子进程、TypeScript runtime 和 File/SQLite 权威库。未测线上历史规模与真实模型成本。
改动思路 / Approach
复用固定子 CLI 已完成的权威读回,保留父进程的独立恢复入口。范围限于显式请求组合结算且首次追加成功。身份、两份前序回执、提交状态和扣额事件都需吻合;重放、响应丢失或验证不通过仍走现有 readback。
具体改动 / Changes
评审 37dead1。GitHub 目标基线 71190b6,实际共同祖先 f4c5d6d7;3 个文件,+90/−7。当前主干的 #8403 改动不重叠,合并树干净。原 Turn 契约 对应 exact-fresh-reuse、ambiguous-readback、non-combined-parity 已验证;live-scale-qualification 另验。
关键代码讲解
- 组合结算入口 仍解析并核对待结算命令,绑定原 Goal、Agent、Todo 和 Turn。
- 新回执核验 只采用匹配的已提交链。任一条件不满足仍调用原权威 reader,再区分未扣额、回执已提交与响应异常。
对主干的风险 / Risks
File 和 SQLite 的真实 CLI 对照中,完整回执把父进程的结算读取从 3 次减至 2 次,与当前主干的等长夹具对照每次少传 8,676 字节。丢失响应、错配 validation 回执、非零子进程退出与重试都保留原读回;独立读到的三份回执一致,每次实际只扣一格。普通 writeback 仍返回原待结算命令且不扣额。114 项相关测试通过、1 个 Windows 专项跳过,标准预合并 6 项直接和 14 项自动检查通过。
我的整体评价 / Verdict
认可当前提交。复用范围与回执证明匹配,异常和重放仍交给原结算 owner;丢失响应后仍能从独立来源证实扣额已提交,重复执行不增加扣额;真实部署规模的延迟收益另验。
English verdict: APPROVE. The fresh proof saves one parent read while incomplete or inconsistent responses and retries still recover the same authoritative chain with exactly one debit.
huangruiteng
left a comment
There was a problem hiding this comment.
Reviewer: model_agent, GPT-5, OpenAI, self_reported
Independent approval
动机 / Motivation
组合 refresh 和 spend 已拿到子进程的权威回执,却再读一次相同结算链。受影响的是使用组合 refresh + spend 的原 Turn 运行者和 Host。用同一已准入的 Todo 对照普通 writeback、首次组合结算和原 Turn 重试;新提交只在新扣额的完整证明吻合时省一次读回,最终仍给出原来的三份回执。complete response 少一次 readback,lost 或错配仍读回。三份 receipt 相同,每 Turn 仅扣一格。证明必须同时匹配原 identity、两份前序 receipt 和新 quota spend event。这是隔离的真实 CLI、子进程、TypeScript runtime 和 File/SQLite 权威库;未测线上历史规模与真实模型成本。不改变扣额规则、不加快普通 refresh、不降低 receipt 验证。
改动思路 / Approach
复用固定子 CLI 已完成的权威读回,保留父进程的独立恢复入口。范围限于显式请求组合结算且首次追加成功。身份、两份前序回执、提交状态和扣额事件都需吻合;重放、响应丢失或验证不通过仍走现有 readback。普通 refresh 不受影响,父进程不会从子进程 stdout 自造一份“成功”状态。本次覆盖 fresh complete、lost response、缺失/错配 receipt、错 Turn、错 event 与 replay。只在完整证明吻合时复用,异常仍回原结算 owner。本次覆盖 complete、lost、错 Turn/receipt/event 和 replay。
具体改动 / Changes
评审 37dead1b39dc91e70bce569d3bca414ba3138388,GitHub 目标基线 71190b6b4ef4e146f3bf4a10d31ce61ac42fd021,3 个文件,+90/−7。三份 receipt 相同,每 Turn 仅扣一格。 原 Turn 契约 对应 exact-fresh-reuse、ambiguous-readback、non-combined-parity 已验证;live-scale-qualification 另验。
关键代码讲解
- 组合结算入口 仍解析并核对待结算命令,绑定原 Goal、Agent、Todo 和 Turn。
- 新回执核验 只采用匹配的已提交三回执链。任一条件不满足仍调用原权威 reader,再区分未扣额、回执已提交和响应异常。
对主干的风险 / Risks
最强反例是子进程返回成功形状,但 receipt 缺一条、前序 receipt 指向别的 writeback、identity 换了 Turn,或 quota event 与 validation/writeback/spend 链不一致;直接复用会掩盖重复扣额或串单。_has_verified_fresh_spend 要求 fresh append、非 replay、非 repair、非 dry-run,三份 schema 化 committed receipt 的 effect_id 全部一致,最后 source_ref 精确绑定唯一 rollout event。lost response 和所有错配都重新读原权威链。
exact head 的 tests/control_plane/test_refresh_settle_turn.py 通过 32/32,覆盖 File/SQLite 的 complete、lost、missing receipt、wrong Turn、wrong writeback、wrong event 和 replay;每次实际只扣一格。普通 writeback 仍返回原待结算命令且不扣额。Git diff 与最新 main merge-tree 均无冲突。远端旧 head 的 pending/failed checks 作为独立 merge-readiness hold。
我的整体评价 / Verdict
认可当前提交。复用范围与回执证明匹配,异常和重放仍交给原结算 owner;丢失响应后仍能从独立来源证实扣额已提交,重复执行不增加扣额。部署规模延迟和真实模型成本另行验收。
English verdict: APPROVE for 37dead1. The fresh proof saves one parent read while incomplete or inconsistent responses and retries still recover the same authoritative chain with exactly one debit.
Combined settlement was looking up the receipt chain again after the quota child had already read it from the authority store. Reuse the child's proof after a fresh append when the original settlement identity, predecessor receipts and spend event all match. Responses that are lost, incomplete or inconsistent, and replays, still use the independent lookup.
The packaged CLI on File and SQLite saved one lookup and about 8.4 KB of internal transfer per successful settlement, with identical CLI output byte counts. The integrated C1 path reproduced the result. Recovery tests cover a lost response after a real debit, missing or mismatched receipts, and idempotent replay.
The standard premerge canary passed. The packaged SQLite CLI also recovered the original receipt chain after an injected response loss following the real debit in each of two Turns.