没认领到验证请求，为什么还会尝试写回它的结果？
假设一项测试已经在运行。第二个执行者到来，存储层告诉它：请求存在，但你没有认领到。接下来最需要弄清楚的，不只是第二个执行者会不会继续跑，还包括它能不能把自己的结果写到第一个请求上。
这个问题来自一次验证持久化改造。Fusion 是一个组织 Agent 开发工作的开源项目，其变更提出：验证启动前先保存请求，避免执行进程消失后连“曾经请求过验证”都查不到。在固定版本的原工具模块中，我们进一步检查了返回的请求身份怎样传到完成回调。
实测得到的窄结论是：**未认领分支仍会执行本次命令，并尝试用返回的旧请求 ID 调用完成接口。**这里的持久化依赖是夹具；数据库是否真正接受更新，需要另一层验证。
先落盘解决了什么，还没有解决什么
Fusion #3590提出为验证补上预先持久化、执行超时和陈旧运行记录回收。它直接回应的是验证生命周期不可见的问题。我们研究时该 PR 尚未合并，固定源码提交为 b5d75aba5e7cdc145921113a1b069db95fa781f7。
请求留下来了，恢复程序才有对象可以查。但这还需要一条对应关系：被保存的工作，是否就是实际运行的工作；认领记录的执行者，是否就是有资格结束它的执行者。
如果只盯着“现在有记录了”，这条对应关系很容易被一个请求 ID 掩盖。
沿着一个 ID 看完成资格
在被检查的工具路径中，持久化回调返回 claimed 和 request。代码先把 request.requestId 保存下来，再处理没有认领到的情况。未认领分支发出警告，但没有停止本次执行，也没有清除已保存的 ID。
随后执行的是本次调用产生的 effectiveCommand。完成函数检查持久化依赖存在、请求 ID 非空，就尝试写结果。
因此，两个问题应分开看：允许另起一次不受跟踪的验证，可能是一项可讨论的可用性选择；把那次结果送给另一个在途请求，则需要独立的归属依据。
我们还查看了存储侧完成函数：更新条件包含任务、请求 ID 和 running 状态。该静态路径帮助定位需要补测的交点，但不能替代实际数据库、并发认领或隔离级别测试。
六个场景穿过原工具入口
实验加载完整上游工具模块，擦除类型后注入明确的测试依赖。我们没有重写待测分支；实际调用原 createRunVerificationTool().execute()。队列立即放行，数据库回调由夹具控制，执行端运行无害的 node --version 子进程。
| 控制条件 | 执行回调 | 完成回调 | 返回或观察 |
|---|---|---|---|
| 新请求正常认领 | 1 | 1 | 先写请求，再执行并收口 |
| 认领结果指向另一命令的旧请求 | 1 | 1 | 跑本次命令，完成回调带旧 ID |
请求在运行，claimed=false | 1 | 1 | 未认领仍尝试完成旧请求 |
| 请求写入抛错 | 1 | 0 | 命令成功，工具返回成功 |
| 执行器抛错 | 1 | 1 | 尝试记录失败，再抛出异常 |
| 完成记录写入抛错 | 1 | 1 | 工具仍返回执行成功 |
图 1：依据本文已保存观测绘制的实验逻辑示意；箭头表示本图标明的处理关系，不是实际运行截图。来源：随文实验附件。
两轮独立进程中的六组语义结果一致。我们特意保留正常失败对照：执行器抛错时，失败收口路径确实存在。结论不是“这个模块完全不处理失败”，而是某些失败与归属信息没有限制后续回调。
“完成回调一次”只表示发出了请求；夹具里变更成功不能被换成“真实数据库成功写错了一次”。
一个成功值装不下两种结果
先写请求失败以后继续运行，体现了一个真实设计取舍：记录系统暂时不可用时，是否仍允许做检查。
如果允许，就应该让调用者分辨“命令执行成功”和“结果已经可靠记录”。否则，一个成功值会让后续恢复者误以为两件事都完成。
反过来，命令成功但完成记录写入失败，也不该自动重跑命令。更合适的恢复动作可能是补交结果；前提是仍能证明结果属于同一请求、同一命令和有资格的执行尝试。
这些是接口评审问题，不能靠加一句“先持久化”一次解决。
从这个实验带走什么
审查类似接口时，可以沿三条关系逐项核对：认领失败是否撤销完成资格；被认领的工作与实际命令是否一致；执行结果和持久化结果是否分别可见。
可选设计包括拒绝不兼容的旧请求、执行已认领请求的原命令，或以新的独立请求记录本次工作。哪一种适用，要由产品合同决定。完成接口还可以要求认领凭证或执行尝试身份，而不只接收一个可读到的请求编号。
这些尚不是 CodeFlowMu 的修复需求。我们没有在本地产品证明相同链路，也没有据此提出重建验证平台。随文证据说明保留六组观测、固定源码与替代依赖；数据库集成、真实排队与完整启动恢复仍未验证。
先保存请求，让系统记得工作存在。保存并检查完成资格，才让系统有理由相信后来的结果属于这份工作。