Files
Genarrative/apps
lhk229 d86ea61a68 审批消费测试改用生产写法收口策划子 Run,补上幂等键冲突的覆盖
approval_receipt_consumes_submit_batch_and_folds_final_provider_usage_once
本该覆盖上一个提交修掉的那条链路,却一直是绿的。原因在夹具:它手搓
child_completed 再用 append_game_creator_agent_runtime_task 写终态,而这个入口
不往记录里写 actionId。生产侧走的是
ensure_project_planning_submit_child_completion_at,它用
append_game_creator_agent_runtime_task_projection_once 把 actionId 一起盖进去。

差别正好落在被测的那把幂等键上。磁盘上没有 (runId, actionId, phase=completed)
这一行,receipt 消费时的投影就找不到冲突对象,顺利追加——于是一条 100% 必现的
线上故障在单测里完全看不见。

改成调用生产入口本身,并按它的前置补齐 durable delivery(沿用同模块 2400 行
一带的既有写法,结果文案与生产的 last_response 一致,避免 publish 时身份不符)。

A/B 验证过测试确实抓得住:临时撤掉上一个提交的修复,此测试报
assertion failed: !first.recovery_pending,正是线上症状;装回修复即通过。

同批 planning_submit 并发跑有 6 条失败,逐条单跑全过,是本机 agent.db 文件锁
竞争,与本改动无关。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 10:46:39 +00:00
..
2026-07-17 16:56:46 +08:00