权威终态到达后迟到的写不能覆盖它

更新于 2026-09-22

权威终态到达后迟到的写不能覆盖它

# 权威终态到达后迟到的写不能覆盖它

结论

一旦权威终态到达（完成事件 / 用户已提交的新内容 / 已确认的结果）， 之后任何迟到、失败、补充的写都不能把它改回进行中或失败。 判据一句话：结算点前移到权威事件本身，而不是等流程自然走完。

四处证据：每一处都是「迟到的写赢了」

出处权威状态迟到的写症状
终态已到达后补写不能覆盖它turn.completed（回答已完成）读 SSE 尾部时的 transport error → catch 用「半截 + failed」覆盖完整回答被截断成半截，或像卡住
过期响应不能覆盖当前编辑内容用户刚输入的新正文晚返回的旧保存请求带回旧 content_md刚写的字被回退
文件被回退先分清是工具还是并发会话已确认的编辑结果另一个会话 / 工具又写了一次文件被回退
中间进展与最终回答要按phase区分最终回答中间进展被当普通消息同步客户端收到一堆半截消息

综合判断

  1. 「流程走完」和「结果已确定」是两件事。 HTTP 200 只代表响应头成功，不保证 body 读完； 流自然结束也不是结算点。一旦权威事件到达，后续的失败与补写就只是噪声。

  2. 降级全部静默。 不会报错，只会「内容变短 / 变旧 / 状态回到进行中」—— 所以第一反应往往是「偶发」。

  3. 可迁移的动作：任何「终态 + 尾部处理」的链路，先问三句 —— 「权威事件是哪一个？」「结算点在哪一行？」「终态之后的错误怎么处理？」 第三问的正确答案是 lifecycle reconciliation：保留终态，不让 catch 覆盖。

  4. 时间窗口很窄是这类 bug 的常态（只在一帧内、只在有思考流的请求里）， 所以必须靠结构（结算点前移）而不是靠复现来修。

与既有 synthesis 的关系

为什么这是 synthesis

单看每一页，都是某次流式 / 编辑 / 并发写的事故。 并排之后才看得出它们共享同一个判据错误：用流程状态代替权威事件。

相关