Skip to content

fix(chat): retain written settings when readback fails - #7458

Merged
loopx-agent merged 1 commit into
mainfrom
codex/managed-calendar-config-recovery-20261027
Oct 27, 2026
Merged

loopx-agent merged 1 commit into
mainfrom
codex/managed-calendar-config-recovery-20261027

Conversation

@loopx-agent

@loopx-agent loopx-agent commented Oct 27, 2026 •

Copy link
Copy Markdown
Collaborator

When an existing Goal setting is saved and its readback fails or disagrees, the API can report an apply error claiming the prior state was preserved. Reuse the existing HTTP 207 partial-write response for every capability with a confirmed source write, retaining the write fact and the existing source-reload action. Normal verified writes, pre-write failures and the original cancellation/execution owners retain their paths.

Real HTTP regressions cover pause, reschedule and clear on File and SQLite with unavailable or mismatched readback. An independent source read confirms the mutation, while a subsequent read/preview performs no additional write, model call, period or external delivery. The same final 12 cases fail against the prior API and pass with this change.

Validation at 2bc0722: 62 configuration/calendar tests pass; standard premerge 6 direct and 11 selected checks, Ruff and compile pass. No new UI controls, response fields, persisted state or background worker. Fault/model transports are synthetic; no production settings or live-model/UI journey is claimed.

Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>

@loopx-agent loopx-agent left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewer: model_agent; gpt-6.1-sol; OpenAI; reasoning_effort=max; runtime_reported; execution_observation_id=cd4d49fb4e3d442a070530ed740565c4c67427ef3775560fa3aabe76db26b118

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

动机 / Motivation

在设置页暂停、改期或清空既有周期任务的用户会遇到这个问题。配置已经保存,但随后的读取失败或内容不一致时,旧接口仍报“原状态保留”;新接口保留已写入事实,明确读回未确认,再由原入口重新读取。File 和 SQLite 均能独立读到已保存的变更;返回 HTTP 207 后重新读取、预览,不重复写入、执行任务或发送消息。本次不创建自然语言任务、不重放失败回合,也不把配置保存视为任务完成或报告送达。

这是可独立使用的故障修复。原来的普通成功测试无法发现“写入成功、读回失败”这一先后关系,用户可能重复提交已经生效的暂停或清空。自然语言创建、统一 Agent 设置完整旅程、真实模型内容及多受众送达仍由既有周期任务工作继续验收。

改动思路 / Approach

原入口先绑定预览与修订,再由 canonical writer 保存;HTTP 读回负责验证观察结果。保存事实和读回资格是两件事。原有 partial_write 回执已经能表达这一区别,前端的联合类型、部分写入提示和重新读取操作也已存在。

在原配置 HTTP owner 复用现有 partial-write 回执即可保留写入事实,无需增加配置状态、恢复队列或调度决策。本 PR 只处理 writer 已确认 written 后,配置读回不可用或不匹配的响应;写前失败、正常成功及取消窗口的生命周期 owner 保持。

取消失败窗口仍由原 after_verified_apply 回调负责。这里未验证时只返回不确定状态,不调用回调,不新增 Task、模型 worker、恢复队列或业务重试。Memory 的专用读回匹配仍保留,共用的只是响应处理。

相同已写入状态 原 API 本次 API
读回不可用或不一致 500,声称原状态保留 207,已写入、读回未确认
正常验证成功 原成功回执 相同路径
尚未写入即失败 原拒绝/错误 相同路径

表格只解释已审源码与下述执行结果,不代替执行证据;未新增图形或渲染验收。

具体改动 / Changes

关键代码讲解

  1. _send_applied_goal_configuration:两处判断从“仅 memory 且已写入”收敛为“已写入”。异常与不匹配都会走原部分写入 helper;written 为假仍拒绝,正常读回后才运行原回调。
  2. _send_partial_write_receipt:原 helper 未改,保留 source_written、readback_verified 与 applied_revision 的关系;无法确认当前源时,applied_revision 为空。HTTP207 不是成功完成证明,错误文本不会带出底层私有异常。
  3. 真实 HTTP 回归:先执行既有原生源任务,再对暂停、改期、清空分别注入写入后的不可用/不一致读取。独立读 registry 验证真实写入;恢复 GET 和预览后要求零写入、零额外模型/消息/提供方发送,且未生成周期 journal。

共三文件 +71/-5,生产 +5/-5、现有测试 +59、文档 +7;没有生成文件、迁移、独立脚本或新配置字段。主代码复用现有 Python HTTP I/O owner,不增加新的跨运行时决策。

依据已接受的 docs/product/periodic-reports.md,spec_revision:71057d44f0d50a3636fcd8796f7c98717ce41742,可在固定版本文档复核。新增的说明段不是独立验收依据。以下是原段落对应的评审标识:

  • calendar-preview-source-readback:implemented。保留相同 preview/apply/CAS,补足保存事实与读回资格的准确响应;12 项故障场景经过真实入口验证。
  • calendar-pause-no-replay:implemented。保留原暂停与未知效果 owner,读回恢复不会重跑业务;现有普通/失败/未知控制包含在最终 62 项中。
  • calendar-clear-verified-lifecycle:out_of_scope。原规范将窗口退休交给验证成功后的生命周期回调;本次只处理其前方未验证读回,不宣称清空后窗口已退休。原正常取消测试仍通过。
  • calendar-parent-journey-boundary:out_of_scope。原规范明确未完成自然语言创建与统一 managed/attached 页面;本次不以响应修复代替这些父级验收。

对主干的风险 / Risks

最值得反对的理由是:把部分写入泛化可能掩盖真正写失败,或者让人误以为取消已经全部完成。此处 writer 的 written 事实是必要条件;回执仍为 ok=false、partial_write,读回未证时不产生 applied_revision、不运行 verified callback。真实 source write 由另一条 registry 读取确认,不能用响应自身证明自己。Memory 诊断不再提示“inspect binding”,但其原匹配器和编辑器没有移除绑定验证,恢复动作仍要求先重新读当前配置。

同一最终测试 harness 在不可变旧 API 上 12 项全部 FAIL:源已经变更,实际却为500;修复后 12 项通过。最终 2bc0722 的两文件完整回归为 PASS:62 项,295.78 秒。标准 premerge 的6项直接检查与11项选中检查、Ruff、编译和公开边界均 PASS,未查询或等待 CI。第一次测试草稿曾把 writes_required 数量0误写成布尔断言,已按既有计数字段改正,随后旧/新版本使用同一最终 harness;未据此改产品合同。

语义与 CI 对齐

复用既有 goal_configuration_transaction_v0 / partial_write 词汇。改变的是有实际写入证据时的响应与通用恢复文案;没有新增权限、预算、调度或模型指令。语义词汇与维护预算检查均通过;单文件 advisory 只覆盖其能识别的词汇,未把空候选当成语义无变化证明。

合成边界保留:HTTP、File/SQLite、原生源任务与配置存储是真实实现;模型和读回故障为注入。未做生产设置故障、断电、真实模型理解或本轮浏览器像素验收。验证成功后的生命周期回调自身失败仍是独立边界,不在本修复中声称已解决。回滚不需改存储格式,但会恢复原误导性错误;故障后应从源读回,不能盲重放写入。

我的整体评价 / Verdict

APPROVE,限定 2bc0722,无阻塞 findings;属于 justified_increment。long_horizon=improved:重新读取后可恢复设置知识且零重复业务;user_experience=improved:沿既有 partialWrite/重新读取入口表达真实状态,不增加用户输入、身份选择或确认轮次。当前权衡是保守地保留未知读回,不能替代任务生命周期验收。

视觉判断为 not_applicable:已检查原设置组件、响应解码和恢复分支;本次没有页面/样式/布局改动。本轮没有新浏览器或像素证据,完整 NL/设置前端与真实模型旅程仍未验证。净零生产行替代 capability 特判,保留单一回执、当前消费者与原 lifecycle owner,机制和维护成本与真实故障相称。后续改动 writer、matcher、回调或前端 DTO 时需重新评审与复测。

English verdict: APPROVE at 2bc0722. No blocking findings; real HTTP/File/SQLite fault cases and 62 exact-head regressions pass. Production UI/model and broader recurring-task acceptance remain unqualified.

@loopx-agent
loopx-agent merged commit 0c75dac into main Oct 27, 2026
14 of 35 checks passed
@loopx-agent
loopx-agent deleted the codex/managed-calendar-config-recovery-20261027 branch October 27, 2026 06:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant