Skip to content

fix(chat): recover private Bot routing outages without replaying work - #6974

Merged
huangruiteng merged 5 commits into
mainfrom
codex/bot-routing-recovery-20261021
Oct 21, 2026
Merged

huangruiteng merged 5 commits into
mainfrom
codex/bot-routing-recovery-20261021

Conversation

@loopx-agent

Copy link
Copy Markdown
Collaborator

Private project assistants and personal stewards could stop permanently after a temporary Codex workspace-routing outage. The recovery path covered a single context migration, and the delivery worker treated a delivered recovery failure as a terminal result.

This change lets the original worker reserve up to three correlated continuations with 60/120/240-second backoff. Every new continuation requires a stable native inventory proving the latest request contains only its input and native compaction bookkeeping, plus fresh source and grant verification. Unknown effects, tools, corrections, changed sources, group audiences and revoked bindings remain excluded. Previously admitted queue work is reconciled by its exact client identity after an acknowledgement loss; it is never submitted again. Each continuation keeps separate presentation receipts and preserves earlier failures.

Validation: native-provider, original-worker recovery, negative boundary and adjacent regression suites; real scanner restart and admission-crash cases; TypeScript owner tests; repository premerge and bilingual diff checks. Final exact-head results are recorded in the review before merge. Live installation and original-source return verification follow merge. No model/provider account change, manual business execution, or native auto-merge is included.

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

Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
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; model=gpt-6.1-sol; provider=OpenAI; runtime_reported; effort=max

动机

使用普通项目私聊助手和个人管家的用户。原请求遇到上游工作区路由超时后,旧版在重试或一次迁移续办失败后停住;新版由原回复 worker 在核验原消息、授权和无业务执行证明后退避续办。已用原消息扫描器和规范队列的合成通路验证两类私聊自动续办、排队确认丢失后的接续及旧失败通知保留。本改动不修复远端模型服务,不扩权、不重放未知效果,也不把合成验收当作线上业务已经完成。合并后仍须正常安装、在原服务空闲边界重启,并独立核验真实原消息自动回传;上游可用性和全部历史积压仍需实际证据。

本次以既有受理/执行/回传合同判断,结论是 justified_increment:代码修复交付可部署的原请求恢复不变量,线上采用和最终业务答复不由测试计数代替。规范:docs/reference/protocols/manager-evidence-and-continuity-v0.md,固定版本 2ed85fc5c169f14526d5e8aceac463c6cc5eb899;逐项核对 origin-request、scope-before-apply、persist-before-effect、unknown-outcome。前两项由原 App、本人、来源和 grant 的重新核验兑现,后两项由先预留后排队、丢失确认后采用确切既有 Turn,以及未知效果保留的反例验证。

改动思路

继续使用既有规范队列、来源围栏和消息 worker;只扩展原有恢复判断与持久化预留,不另建执行者或第二套排队 authority。本 PR 同时交付原生无执行证明、类型化准入、崩溃后既有排队关联和分次回传凭证;实际安装与真实业务回传由部署验收继续核验。原有同轮传输重试与一次性上下文迁移保持各自边界,新增的是已经证明未执行业务的路由失败退避路径。只认可两种固定的 provider 诊断;压缩记账不是业务工具执行,完整原生清单仍不得包含回答、工具、额外用户输入或未知项。60/120/240 秒退避和至多三次续办从持久化失败计算,重启不能清零。

原触发 旧行为 当前精确版本的结果
私聊请求发生路由或压缩阶段路由超时 项目助手不进入迁移恢复,管家一次续办失败后停住 原 worker 重新核验来源、授权和无执行业务证明后退避续办
排队成功但关联记录未确认 恢复可能卡住或重派 按原 client 身份采用规范队列里已受理、甚至已完成的 Turn
工具、未知效果、改过的来源或已撤销授权 需要原有持有与核验 保持拒绝,不把 listener 健康或失败通知送达当作许可

具体改动

审查头为 b8c7cb90ccd1d6ab7afa1633899fc819561a4fd5。planContextRecovery 与 planRoutingRecovery 保持 TS 决策归属,绑定原私聊角色、Goal、channel、grant、原请求与上游失败;原队列已受理时只同步该确切身份。ChatExternalConversations.recover_failed_request 在排队前持久化预留,保存早先的恢复记录,并按确切 client 查回丢失确认的既有工作。failed_request_readback 移到现有 Codex provider adapter,与唯一生产观察调用者放在一起,完整分页及前后两次终态核验继续生效,既有 session 方法删除而不增加兼容 facade。

LarkPrivateConversations.reconcile_request 不再把已回传的续办失败直接当成闭环;presentation_phase、presentation_stream 为每次路由尝试分开保存草稿和最终凭证,原失败文件和旧通知保留。三份测试覆盖规范队列、原扫描器、两种私聊、丢失排队确认、重启、两种原生条目顺序及来源/授权/作用域反例;RFC 中英文同时说明默认行为变化。没有新进程、第二消费者、CLI、账号配置或技能安装面。

对主干的风险

主要风险是错误地把执行效果未知判成没有执行、重复排队,或把其他受众的权限带进恢复。具体反例已走原扫描器和 TS owner:额外工具/回答/用户项、未知或跨 Turn 条目、修改来源、撤销授权、外部 Goal/channel、群受众、变化 grant、活动工作和预算耗尽均不应产生新续办。已完成的同 client 规范工作属于丢失确认的接续,测试要求不再次 enqueue。旧迁移路径和原呈现 key 保留,未通过放宽预算或删除历史失败来获得绿灯。

源码 native/扫描器回归 490 项、相邻回归 263 项、TS owner 28 项通过;安装 wheel 的 Python 3.12 同组 490 项通过,产品模块与审查头逐字节一致。不可变基线运行相同正向扫描器场景,两类私聊均失败,当前 12 项扫描器/断点/拒绝场景通过。仓库 premerge、模块维护性、语义词汇和中英文 RFC 差异检查通过。早期的排队确认缺口和不确定时钟测试失败已保留并分别修复;缺少前端打包资源、测试依赖的环境失败也保留,经正常准备后复验。按 Goal 配置 wait_for_ci=false,未查询、轮询或等待远端 CI。

我的整体评价

APPROVE,作为修复默认恢复机制的连贯增量可合并。继续使用既有规范队列、来源围栏和消息 worker;只扩展原有恢复判断与持久化预留,不另建执行者或第二套排队 authority。这个边界同时兑现持久预留、规范排队和原受众结果保留,单纯重启或调大重试次数无法替代;原生观察函数的移动还降低了已有大模块的增长压力。没有发现当前精确头的阻塞缺陷。最多三次的有界恢复仍可能遇到远端持续故障,新诊断格式或较新的原生请求保持保守持有;不声称远端已修好、所有旧积压已完成,或合成 provider 等于线上模型。维护者已授权本次自合并,仍需精确版本 readiness 与正常安装后的原消息验收;不启用原生自动合并。

English verdict: APPROVE — b8c7cb90ccd1d6ab7afa1633899fc819561a4fd5 restores bounded original private-worker routing recovery, reconciles acknowledged queue work without replay, and preserves source/grant/effect boundaries. Source, installed-wheel, TypeScript and required local checks pass; live deployment and upstream availability remain separate acceptance.

@huangruiteng
huangruiteng merged commit 1323053 into main Oct 21, 2026
29 of 43 checks passed
@huangruiteng
huangruiteng deleted the codex/bot-routing-recovery-20261021 branch October 21, 2026 03:33

@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; model=gpt-6.1-sol; provider=OpenAI; runtime_reported; effort=max

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

动机

使用普通项目私聊助手和个人管家的用户。原请求遇到上游工作区路由超时后,旧版在重试或一次迁移续办失败后停住;新版由原回复 worker 在核验原消息、授权和无业务执行证明后退避续办。已用原消息扫描器和规范队列的合成通路验证两类私聊自动续办、排队确认丢失后的接续及旧失败通知保留。本改动不修复远端模型服务,不扩权、不重放未知效果,也不把合成验收当作线上业务已经完成。合并后仍须正常安装、在原服务空闲边界重启,并独立核验真实原消息自动回传;上游可用性和全部历史积压仍需实际证据。

本次以既有受理/执行/回传合同判断,结论是 justified_increment:代码修复交付可部署的原请求恢复不变量,线上采用和最终业务答复不由测试计数代替。规范:docs/reference/protocols/manager-evidence-and-continuity-v0.md,固定版本 2ed85fc5c169f14526d5e8aceac463c6cc5eb899;逐项核对 origin-request、scope-before-apply、persist-before-effect、unknown-outcome。前两项由原 App、本人、来源和 grant 的重新核验兑现,后两项由先预留后排队、丢失确认后采用确切既有 Turn,以及未知效果保留的反例验证。

改动思路

继续使用既有规范队列、来源围栏和消息 worker;只扩展原有恢复判断与持久化预留,不另建执行者或第二套排队 authority。本 PR 同时交付原生无执行证明、类型化准入、崩溃后既有排队关联和分次回传凭证;实际安装与真实业务回传由部署验收继续核验。原有同轮传输重试与一次性上下文迁移保持各自边界,新增的是已经证明未执行业务的路由失败退避路径。只认可两种固定的 provider 诊断;压缩记账不是业务工具执行,完整原生清单仍不得包含回答、工具、额外用户输入或未知项。60/120/240 秒退避和至多三次续办从持久化失败计算,重启不能清零。

原触发 旧行为 当前精确版本的结果
私聊请求发生路由或压缩阶段路由超时 项目助手不进入迁移恢复,管家一次续办失败后停住 原 worker 重新核验来源、授权和无执行业务证明后退避续办
排队成功但关联记录未确认 恢复可能卡住或重派 按原 client 身份采用规范队列里已受理、甚至已完成的 Turn
工具、未知效果、改过的来源或已撤销授权 需要原有持有与核验 保持拒绝,不把 listener 健康或失败通知送达当作许可

具体改动

审查头为 b8c7cb90ccd1d6ab7afa1633899fc819561a4fd5。planContextRecovery 与 planRoutingRecovery 保持 TS 决策归属,绑定原私聊角色、Goal、channel、grant、原请求与上游失败;原队列已受理时只同步该确切身份。ChatExternalConversations.recover_failed_request 在排队前持久化预留,保存早先的恢复记录,并按确切 client 查回丢失确认的既有工作。failed_request_readback 移到现有 Codex provider adapter,与唯一生产观察调用者放在一起,完整分页及前后两次终态核验继续生效,既有 session 方法删除而不增加兼容 facade。

LarkPrivateConversations.reconcile_request 不再把已回传的续办失败直接当成闭环;presentation_phase、presentation_stream 为每次路由尝试分开保存草稿和最终凭证,原失败文件和旧通知保留。三份测试覆盖规范队列、原扫描器、两种私聊、丢失排队确认、重启、两种原生条目顺序及来源/授权/作用域反例;RFC 中英文同时说明默认行为变化。没有新进程、第二消费者、CLI、账号配置或技能安装面。

对主干的风险

主要风险是错误地把执行效果未知判成没有执行、重复排队,或把其他受众的权限带进恢复。具体反例已走原扫描器和 TS owner:额外工具/回答/用户项、未知或跨 Turn 条目、修改来源、撤销授权、外部 Goal/channel、群受众、变化 grant、活动工作和预算耗尽均不应产生新续办。已完成的同 client 规范工作属于丢失确认的接续,测试要求不再次 enqueue。旧迁移路径和原呈现 key 保留,未通过放宽预算或删除历史失败来获得绿灯。

源码 native/扫描器回归 490 项、相邻回归 263 项、TS owner 28 项通过;安装 wheel 的 Python 3.12 同组 490 项通过,产品模块与审查头逐字节一致。不可变基线运行相同正向扫描器场景,两类私聊均失败,当前 12 项扫描器/断点/拒绝场景通过。仓库 premerge、模块维护性、语义词汇和中英文 RFC 差异检查通过。早期的排队确认缺口和不确定时钟测试失败已保留并分别修复;缺少前端打包资源、测试依赖的环境失败也保留,经正常准备后复验。按 Goal 配置 wait_for_ci=false,未查询、轮询或等待远端 CI。

我的整体评价

APPROVE,作为修复默认恢复机制的连贯增量可合并。继续使用既有规范队列、来源围栏和消息 worker;只扩展原有恢复判断与持久化预留,不另建执行者或第二套排队 authority。这个边界同时兑现持久预留、规范排队和原受众结果保留,单纯重启或调大重试次数无法替代;原生观察函数的移动还降低了已有大模块的增长压力。没有发现当前精确头的阻塞缺陷。最多三次的有界恢复仍可能遇到远端持续故障,新诊断格式或较新的原生请求保持保守持有;不声称远端已修好、所有旧积压已完成,或合成 provider 等于线上模型。维护者已授权本次自合并,仍需精确版本 readiness 与正常安装后的原消息验收;不启用原生自动合并。

English verdict: APPROVE — b8c7cb90ccd1d6ab7afa1633899fc819561a4fd5 restores bounded original private-worker routing recovery, reconciles acknowledged queue work without replay, and preserves source/grant/effect boundaries. Source, installed-wheel, TypeScript and required local checks pass; live deployment and upstream availability remain separate acceptance.

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.

2 participants