补偿隔离与冲突接管
全库目录221
本文目录5
任务J创建房间R与桌子T，移动A形成挡路布局，移动B让出通道，验证尝试V2通过后进入审核。取消时依次撤销B、A与创建操作；撤销B会暂时恢复挡路状态。本文说明这类中间态的隔离、人工编辑冲突，以及残留对象的维护接管。版本游标与墓碑机制见场景补偿的版本承接。
补偿中间状态与最终门禁
J的A布局挡住通路，B才把通路让开。取消先撤销B，必然再次经过A的布局，再撤销A和创建操作。如果每一步都要求通过正式布局的导航门禁，这条正常取消链会停在第一步。任务因此分别记录宿主硬约束、补偿中间检查和发布门禁，规则集明确每条规则属于哪一类。
宿主硬约束保护每次提交都必须成立的条件：对象身份及版本匹配、授权有效、变换有限且可表示、父子关系无环、引用有目标，以及宿主资源容量上限。违反这些条件时整步拒绝，保持原场景，进入补偿冲突或明确的容量故障。布局通路、家具穿插、艺术净空与目标渲染预算属于最终布局门禁；其未通过的中间结果记录具体失败项，留给后续补偿继续消除。
这种中间态在任务专属暂存场景内执行。进入Cancelling时，宿主在同一许可入口关闭该场景的正向业务写入、运行模拟、普通预览交付和发布许可，保存补偿会话ID、起始快照及补偿列表；已接纳消费者先退出或固定自己的不可变快照，再开放补偿写入。维护预览明确读取Compensating快照与失败项，正式消费者继续读取原已发布版本。宿主只接受补偿列表或审核决议授权的操作；Cancelling允许这些操作通过，普通规划命令仍被拒绝。人工工具的编辑仍走版本入口，并使受影响的补偿条件失配。
每一步先在当前不可变快照上计算候选，检查硬约束，同时产生布局诊断；只有硬约束通过才条件提交。导航诊断绑定候选几何哈希，尚无匹配导航数据时记Pending，不借用旧导航宣称可达。匹配数据就绪后按该候选重新绑定交互支撑层、投影站位并检查姿态与路线；诊断只归属这份候选，下一补偿已改变场景时只能补齐历史记录。中间诊断的Pending或失败均不授权发布，也不阻止逆序清理。硬约束规则、诊断规则和快照读取版本都写入补偿尝试。补偿会话与当前隔离状态由宿主耐久保存，重启先恢复它们再开放入口。
没有外部编辑时，撤销B恢复A的局部布局并产生v4，通路失败随回执记录；执行器继续撤销A产生v5，再删除T、删除空房间R，按墓碑确认所有任务对象已清理，进入Cancelled。场景为空时验收对象与关系清单为空，不对已删除座位继续查询通路。若人工编辑造成冲突，就保留隔离与当前游标，按本页“冲突决议与续行”处理。
含Retained或Waived的结果先形成完整残留清单。J的在途操作全部结清后，维护方创建接管任务JR，引用该清单与不可变残留快照；宿主关闭J的补偿写入权限，按场景工具的条件执行授予JR维护权限。J保持取消终态，JR承担后续修复、审核与发布。
JR建立验证尝试VR1，绑定最终残留快照哈希、读取集合、角色与规则版本。VR1重新生成站位区域、目标表面接触及完整路线；补偿中间候选的迟到结果只补原尝试，原V2也保持历史归属。后续人工修改产生新哈希时，让VR1失效并建立VR2，审核消费被当前快照接纳的那一次完整报告。
未通过或导航仍Pending时，原任务J仍报告CancelledWithRetainedObjects，但残留资产继续由维护方接管，场景保持隔离并返回门禁结果；清理终态不代表可运行或可发布。门禁通过后形成绑定VR1或其后继验证身份、最终快照与报告哈希的新审核候选，JR的批准记录引用该候选，按资产任务编排与发布交付。已发布任务的取消先按撤回协议处理正式入口，暂存补偿不会直接改写消费者正在使用的不可变版本。
冲突决议与续行
冲突记录保存待补偿项、预期与实际版本、实际字段差异、受阻后继和场景快照哈希。任务停止这条依赖链，独立且无共享写集合的补偿可以继续；取消入口仍关闭新业务派发。审核决议拥有稳定决议ID，绑定冲突记录代次、观察到的全部对象与关系版本，以及明确的恢复目标。决议的接纳、游标变更和依赖状态共同持久化；审核期间对象再变化，条件比较失败，产生新一轮冲突。
| 决议 | 宿主与登记动作 | 后继处理 |
|---|---|---|
| 保留人工结果 | 比较观察版本，保存保留对象与关系的回执，将该对象剩余补偿项置为Retained | 删除依赖这些对象的父对象同样置为Retained，保留关系闭包；其他独立项继续 |
| 批准恢复 | 比较观察版本，把审核批准的完整目标字段作为新的补偿操作执行，回执记录决议ID与新版本 | 以新回执承接游标，继续审核指定的剩余补偿项；再次冲突就停止 |
| 放弃本项补偿 | 明确把当前实际状态列为残留并置为Waived，保存责任人与原因 | 默认把同对象剩余补偿置为Retained，并向父关系传播保留闭包；只有审核逐项绑定剩余补偿及恢复目标才允许继续，不能当作已经删除 |
例如撤销B产生v4后，人工改色生成v5，撤销A冲突。批准恢复可以只恢复A的原位置而保留v5颜色：审核目标明确列出这两项，宿主比较v5后产生v6。接下来删除T仍会删除人工颜色，所以批准恢复必须同时逐项批准“继续删除T”，或者把创建补偿标为Retained；批准一次移动不隐含批准删除。选择保留T时，A与创建T的补偿转Retained，R及其挂接关系随之保留，其他临时预览仍可删除。
若在撤销B发生冲突时选择放弃B，默认保持T的实际状态：B为Waived，A和创建T为Retained，R也进入保留闭包。调度器不能仅跳过B再撤销A或删除T；这会绕过“当前状态列为残留”的决议。需要继续A时，审核决议必须列出A和后续创建补偿各自的目标及保留/删除选择，宿主仍按观察版本和决议ID条件提交。
宿主已执行决议而调度器崩溃时，以决议ID查询回执，补齐游标与依赖标记；未取得回执时先查询原决议是否仍在排队或执行，保留隔离并等待其确定终态；确认未接纳且旧提交权限已关闭、旧队列项与在途调用均退出后，才比较观察版本并执行。宿主在提交事务中按决议ID去重，同一ID的重复提交返回原回执。重复审核提交返回原决议，新的决议只能针对尚未结清的冲突代次。全部在途请求已对账、所有补偿项为Compensated时进入Cancelled；含Retained或Waived则进入CancelledWithRetainedObjects，并输出对象、关系及责任清单。存在未决冲突始终保持CompensationConflict。取消结果的消费者据终态决定释放任务配额，并据残留清单接管保留资产，不能把“取消完成”解释成空场景。
实现与证据
本页说明资产管线的设计协议与接口条件，未部署Agent、连接DCC、构建实际导航或执行资产发布。公式与数例可作机制推演，宿主事务、幂等性、恢复和发布仍需由各工具实现验证。事务边界的可运行示例见RPC。
相关主题
参考资料
- SQLite Transaction：本地操作登记的事务边界。
- etcd API guarantees：条件事务与发布指针仲裁；场景工具不由数据库自动获得原子性。