Skip to content

Hold private steward input during executor adoption - #8592

Merged
huangruiteng merged 1 commit into
mainfrom
codex/hold-steward-executor-adoption-20261111
Nov 11, 2026
Merged

huangruiteng merged 1 commit into
mainfrom
codex/hold-steward-executor-adoption-20261111

Conversation

@loopx-agent

Copy link
Copy Markdown
Collaborator

Goal and delivered outcome

When an owner-private steward Session has already switched executors, the old binding can still send a new message to the previous executor. That can open another Session or turn a temporary mismatch into a permanent rejection before the original Session gets a Turn.

The Core request planner now keeps that message prepared against the exact original Session. The existing Lark worker checks local readiness while the binding is stale, then verifies the original source and admits the same request once the binding agrees. Closing the original Session before admission ends the request. A terminal rejection stays historical.

Author declaration

Criterion Disposition Owner and proof
Continue the original private Session and keep its source and grant Implemented The Core request planner uses the existing bound-context check. The original Lark worker queues one Turn after publication of the aligned binding.
Keep a captured request across a lost acknowledgement Implemented The provider and native protocol regression interrupts the Lark journal update after Core admission and recovers the same Turn.
Respect closure and retain terminal receipts Implemented The closed-Session case creates no replacement, and the original receipt is byte-for-byte unchanged.

Scope and continuation

This change owns the interval between executor adoption and publication of the binding. The binding reconciliation change supplies the separate startup publication path. The installed services and a naturally arriving message need their own acceptance after adoption.

Validation

Tested revision d80c03b52c82c8b64960ff8549eb0bb79a5e7d8f. Input classes were synthetic and authorized private metadata read only.

Check Result Evidence
Failing-before comparison Passed On the base, the original private route regression tried to open the previous executor. The candidate held the same request and processed it after binding alignment.
Original worker integration Passed The synthetic Lark provider and Codex protocol cover successful recovery and verified final delivery, closure, and an interrupted Lark acknowledgement after Core admission.
Core planner and scope Passed The TypeScript binding and conversation-scope suites passed.
Isolated installed-shape comparison Passed An isolated copy of the binding and Session metadata reproduced selection of the old executor. The candidate preserved the source and Session and created one queued Turn after alignment. No live adapter was started.
Repository premerge checks Passed The standard canary covers the changed source, bilingual RFC, maintainability ratchet and public boundary.
Adjacent registry fixture Failed on base and candidate The portfolio paging fixture lacks required Goal activation metadata. The same registry check fails on both revisions before request admission.

Frontend and visual evidence are not applicable. The change is in admission and scheduling of existing private messages.

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 family, OpenAI, self_reported

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

Reviewed exact head: d80c03b

动机 / Motivation

从本人原管家私聊发普通消息的用户。原 Session 已采用新执行器,私聊绑定仍保存旧端点,此时收到普通消息。旧路由找不到匹配会话时会尝试打开旧执行器,暂时不一致可变成终态拒绝。原来源合成测试完成一次原 Session 执行并读回回传,关闭和回执中断均没有替代执行。历史终态请求、绑定发布、运行中的 Turn 和群聊沿各自现有生命周期。生产采用及自然消息验收仍待执行。分页及两项来源发现 fixture 在基线与候选同样失败。

改动思路 / Approach

本次范围是本人原管家私聊在 Session 采用新执行器到绑定对齐之间的请求受理。Core 复用原来源与上下文规则判定。Python 保存原请求,Lark 原 worker 按本地状态重试受理。原请求已持久化,绑定未就绪时保留同一请求和会话。正常匹配的请求继续使用现有准入路径。恢复后走同一次原请求校验和原队列。

具体改动 / Changes

  • C1 loopx/control_plane/collaboration/conversation_binding.ts:668 在 preferred 或 pinned 的原管家 Session 已采用另一执行器时,按同一原来源、工作区、operator 和授权保留待准入。共享的上下文比较同时服务正常原会话解析。loopx/capabilities/native_chat/external_conversations.py:1551 持久化原 Session 和等待原因。
  • C2 loopx/extensions/lark/private_conversations.py:1953 与 loopx/extensions/lark/private_delivery_discovery.py:13 通过原请求和本地绑定判断是否继续等候。对齐后原 worker 读取原消息并准入,准入前关闭原 Session 时结束请求。tests/test_lark_private_conversations.py:24 覆盖对齐补办、关闭和 Core 已受理后丢失 Lark 回执,读取原回传并校验只执行一次。原会话契约

对主干的风险 / Risks

风险在于等待期间误用新会话、重复受理或让暂存队列反复访问提供方。候选冻结原 Session,只在入口读到本地状态变化后重新校验原消息。基线在相同合成条件下试图打开旧端点。候选定向回归、68 项 Core 测试和标准预检通过。分页测试在主干及候选都因旧注册表缺少激活信息失败。两项来源发现测试也在两版重复同一读取异常断言,涉及既有 discovery 路径。隔离数据复现覆盖原状态形状,安装与实际回传仍需单独验收。

我的整体评价 / Verdict

本次修复约束了原服务两次持久化之间的消息处理。原消息由同一 worker 核验后入同一 Session,回执中断按现有请求标识恢复。作者复核覆盖此提交的公开差异。运行时改动进入主干仍需独立评审,实际采用后再验自然消息。

English verdict: APPROVE

@huangruiteng
huangruiteng merged commit 896ef5e into main Nov 11, 2026
17 of 20 checks passed
@huangruiteng
huangruiteng deleted the codex/hold-steward-executor-adoption-20261111 branch November 11, 2026 10:54
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