Skip to content

fix(chat): fence prepared recovery and reject in-flight binding changes - #6695

Merged
loopx-agent merged 1 commit into
mainfrom
codex/chat-fenced-recovery-20261017
Oct 17, 2026
Merged

loopx-agent merged 1 commit into
mainfrom
codex/chat-fenced-recovery-20261017

Conversation

@loopx-agent

Copy link
Copy Markdown
Collaborator

A binding revoked or replaced while provider identity is being observed could still authorize a request from the earlier snapshot. Reread the exact binding before passing the current state to the typed owner; unrelated binding edits remain valid.

Prepared request recovery now enters the existing request/source-fenced admission directly, where fresh authorization already runs. This removes the duplicate identity probe before the fences while retaining the frozen original stop target, native control, delivery checks and existing retry journal. No identity cache, persisted format or new consumer is added.

Validation: 275 affected runtime tests, including 8 new cases; the exact new oracle reports 6 failures and 2 passes with the immutable baseline methods. Real App/typed Core read-only recovery measurements confirm two identity invocations become one, without claiming a whole-stop latency improvement. Ruff, configured mypy, normal wheel/Chat build, isolated installed doctor and installed HTTP assets passed. The optional strict leaf check retains the same 11 function-scoped baseline errors. Installed total stop/web timing and full community acceptance remain separate.

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 · runtime_reported · reasoning_effort=max

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

APPROVE at 89a90408d8d61f6a44ebae4ae1a04835fa731755. This is an author-side model review, recorded as COMMENTED because GitHub disallows formal self-approval. It is not independent human approval.

动机

使用已绑定的项目或管家对话、等待停止结果的用户。

身份读取较慢时,旧实现可能继续使用读取前的绑定快照,即使期间已解绑或换绑;恢复已保存的请求还会先多查一次身份,随后等待原请求与来源锁,再做真正的授权核验。

此版本在身份读取后重新检查确切绑定,并让恢复直接复用锁内授权入口。撤回或替换绑定会拒绝继续;同一次恢复少一次身份调用,原停止目标和回复归属保留。

本次没有新增用户步骤、身份缓存、状态格式、消费者或授权,也不把减少一次调用当作完整停止时限通过。

真实安装后的完整停止回执与网页及时可读仍需验收;此前超时失败和完整社区准出缺口继续保留。

改动思路

新鲜授权由现有受理入口在原请求与来源锁内负责,provider等待后的确切绑定检查属于既有文件观测层;typed Core继续决定上下文与权限。

本PR完整交付准备态恢复的调用收拢和绑定观测竞态修复;安装、原话题时限与完整社区验收由现有社区交付任务继续。

这里的准备态是已经写入原请求日志、等待继续处理的请求。原先的外层身份读取既不能替代等待锁之后的授权,也没有控制原生效果;因此应删除外层重复读取,复用现有入口,而非新加身份缓存、队列或恢复服务。单独删掉它仍会留下共享绑定读取的竞态,所以同一有界变更还需在provider观测后重读确切绑定。

下面是准确head 89a90408d8d61f6a44ebae4ae1a04835fa731755 的源码时序对照,属于解释示意,使用表格替代未验证渲染的图,不作为执行证据。

触发 原行为 此版本
已保存准备态请求恢复 锁外查身份,等待原请求/来源锁,再查身份 直接进入既有锁内受理入口
身份读取中解绑或换绑 可能把旧绑定快照交给typed owner 重读确切绑定,不一致即拒绝
同文件另一绑定修改 当前请求应可继续 只比较确切绑定行,仍允许
后来Turn或其它会话 不属于旧停止目标 仍由原冻结目标及原生控制owner隔离

没有引入新权威状态:前后两份绑定行都来自原文件,仅为本次调用的观测;配置和撤权仍由现有typed owner发布。文件观测留在既有Python边界,权限与上下文决定继续由TypeScript负责。未来重构检查已落实为复用唯一的锁内授权路径,没有为一次优化创建另一层框架。

具体改动

五个文件共 136+/5-,其中两处运行方法、既有测试文件以及两个RFC镜像。没有新增CLI、设置、schema或持久字段,也没有将私有探针和原消息日志加入公开变更。

关键代码讲解

  1. ChatConversationBindings.resolve:先找原绑定并观测当前App身份,观测返回后重新读取完整绑定文件。确切绑定已撤回或替换时抛出通用错误;其它绑定变化不使它失效。只有通过这一步才把当前文件和观测交给原typed bound_context,没有跨调用复用身份或把观测当缓存授权。all_registered 的现有注册范围也在这次观测之后获取。
  2. ChatExternalConversations.recover:准备态直接调用原 admit,后者先拿原请求锁和来源路由锁,再做新鲜授权;处理后继续下一条,避免落到非准备态分支。排队命令、已受理工作、已完成和已送达状态的原恢复规则保持。原停止目标固定、实际中断与原话题回传均未另设owner。

规范依据为 docs/architecture/rfcs/app-conversation-and-async-inbox-v0.md,接受的变更前版本 04b929ac609881d1104308e184c980e7af853b45;这些为原无编号条款的描述标签,不是从新实现反推的验收标准。

criterion_id 本head处置
current-binding implemented:原App/source和当前权限决定可否继续;观测中解绑/换绑拒绝,另一绑定修改仍合法。
frozen-stop implemented:仍只缩小原Session/Turn目标;后来工作、其它子进程和已完成回执不受旧stop影响。
separate-live-exits deferred:安装、整条stop/web时限及完整社区准出继续由既有交付owner验收。

新增8个用例包含私聊/群聊各自的撤权、换绑、无关修改,以及等待来源锁期间的允许/撤权两条恢复轨迹。使用真实文件存储和typed owner;停止用例通过协议fixture控制两个实际子进程,验证原归属子进程终止、外部子进程保留、旧Turn回执不改、原话题只回一次。provider与原生wire仍是合成边界,不冒充真实安装的模型/飞书完整旅程。

对主干的风险

主要风险是把严格拒绝做成无关工作也不能继续,或删除锁外探测时误删真正的锁内授权。相同最终测试oracle在不可变base的两个原方法上6 failed/2 passed:四个撤权/换绑窗口仍能得到旧授权,两个恢复轨迹在锁外就发起provider读取;无关绑定两例本来就通过。当前8例全部通过,保留了合法分支;撤权恢复不调用原生控制、不新增provider写入,原准备态冻结集合与所有旧回执保持。原实现的错误输出并非新的兼容要求。

完整六模块275项及自动通知的19项另行通过,覆盖默认listener/reply worker、私聊/群聊、后续Turn、断开、旧原生会话和管家自动通知消费者。原子文件读取是既有存储操作;本修复消除的是provider等待期间的旧快照窗口,没有声称所有后续效果都与任意未来撤权全局原子化。

真实App/typed Core只读恢复使用原来源及授权、独立临时请求日志,并在原生效果边界前停止:base每次2个身份调用,head每次1个,原日志和授权字节不变。provider等待非常波动,profile主要落在等待子进程返回,不能据此归因其内部CPU、服务器或网络,也不能从非交替时序推导整条时延改善。此前实际停止时限失败没有被删除或改口径。

语义与 CI 对齐

当前Goal策略 wait_for_ci=false,没有获取、轮询或等待远端CI。准确head标准native premerge全部通过且无manual hold;Goal的change-quality资格策略为disabled,没有伪造资格收据。Ruff、配置mypy的17个文件、普通Chat/wheel构建、隔离安装doctor和安装后真实HTTP资源检查均通过。另行严格检查两个leaf的11项旧类型错误,已按函数与完整诊断与不可变base逐项相等;不声称全仓strict通过,也不通过放宽门检隐藏它们。

我的整体评价

APPROVE,交付判断为 justified_increment;long_horizon=preserved,user_experience=preserved。用户仍只需要原来的一条普通停止指令,额外必需的人类语句、确认、复制已知信息与导航均为零。既有队列、原结果去重、错误恢复和自动通知保留;从已证明的竞态中拒绝旧授权,同时减少一项无效网络工作,是可以独立使用、回滚和继续验收的改动。

新鲜授权由现有受理入口在原请求与来源锁内负责,provider等待后的确切绑定检查属于既有文件观测层;typed Core继续决定上下文与权限。

本PR完整交付准备态恢复的调用收拢和绑定观测竞态修复;安装、原话题时限与完整社区验收由现有社区交付任务继续。

兼容处理保留真实持久化请求/回执,未保留多余的当前请求授权路径;没有新增版本解码器、手动同步或默认关闭的功能。复用既有语义词汇和typed owner,生产体积与两个真实问题相称。后续若继续优化身份CLI等待,仍须独立验证当前App与授权,不能靠缓存消去权限检查。原安装、网页及时可读、完整黄金查询及隐私门禁的未验部分不由这次源码评审覆盖。

English verdict: APPROVE at 89a9040. The exact regression oracle reproduces stale grants and pre-fence probing on the baseline and passes at this head. Existing File/typed ownership, frozen targets and legal unrelated work are preserved;275 runtime and19 notifier cases plus native premerge passed. Real read-only recovery confirms one fewer identity invocation, not a whole-stop SLA or installed community release qualification.

@loopx-agent
loopx-agent merged commit 8da34be into main Oct 17, 2026
18 of 27 checks passed
@loopx-agent
loopx-agent deleted the codex/chat-fenced-recovery-20261017 branch October 17, 2026 00:08
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