Skip to content

fix(chat): avoid repeated source scans during recovery discovery - #8145

Merged
loopx-agent merged 1 commit into
mainfrom
codex/recovery-discovery-control-read-20261106
Nov 5, 2026
Merged

loopx-agent merged 1 commit into
mainfrom
codex/recovery-discovery-control-read-20261106

Conversation

@loopx-agent

Copy link
Copy Markdown
Collaborator

Historical Antigravity failures repeatedly reread the entire source request inventory while the Lark coordinator discovers recovery candidates. That synchronous work delays delivery discovery for both existing replies and App projections.

Reuse the existing scan-local source-control observation for the later-input hint as well as stop checks. The typed recovery planner, fresh recovery admission, source/binding/stop checks, worker capacity, durable queues and provider effects retain their existing owners. Each new discovery pass reads again; an old hint cannot authorize execution.

Validation at 7e99d1393b63b4e643218b588cf6d7063e9fda56:

  • 12 real Core/transport fixture checks pass, including a later source input after a retained discovery hint, original failure preservation, stop/source changes, unknown tools, missing capacity, no duplicate dispatch, normal quota backlog and discovery backoff.
  • Both scan-count regressions fail on the unchanged base implementation (3 inventories rather than 1). The actual admission check still rejects continuation after later input.
  • Same offline retained-history workload, same product interpreter, 3 alternating pairs: median discovery 3.7377 → 2.0038 seconds; full source reads 8 → 1; all 43 candidate paths match. These are local fixture measurements, not production latency or a full stability claim.
  • Standard premerge, Python compilation, bilingual-RFC and diff checks pass. The existing control-plane maintainability advisory is disclosed separately; no threshold is changed. Change-quality policy is disabled for this managed scope.

This repairs one existing IO consumer. It adds no public capability, configuration, queue, cache lifetime, scheduler, service, model invocation or frontend interaction. App/Lark still use the original shared delivery path. Live delivery under concurrent historical probes, account availability and other outstanding requests remain separate acceptance.

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)

动机 / Motivation

Lark 用户等待原回复或 App 消息同步时,会受到同一个恢复发现循环的影响。旧路径为每个历史 Antigravity 失败重复扫描全部请求;新路径在同一次发现中复用已有观察,下一次发现重新读取。同一离线历史负载的三组交替测量中,中位发现耗时由 3.7377 秒降为 2.0038 秒,八次全量读取降为一次,43 条候选路径一致。本 PR 仅减少恢复发现的重复 IO,不新增队列、执行者、配置或权限。并发生产延迟、上游额度与全部历史欠答仍须沿原服务分别验收,本次局部测量不等于系统稳定性完成。

改动思路 / Approach

选择复用现有扫描观察,而不是增加全局缓存、时间预算或第二发现线程,能够直接减少已测重复 IO 并保留原准入边界。当前 PR 只修改 later-input 的发现读取来源,并扩展既有原 worker 回归;实际恢复仍读新事实,历史发送和失败记录继续保留。入口仍为 pending_delivery_paths,经 context_recovery_observer 收集原请求、Turn 和绑定;TS planner 保留决定权。Python 不新增恢复决策或发送路径。一次扫描可保留观察,不能用观察授予执行;原 worker 的 recover_failed_request 不接收这个对象,实际执行仍在原来源与权限检查下进行。对这个局部 iterable 修改,正文比示意图更直接。

具体改动 / Changes

依据 docs/development/testing-and-quality.md#roadmap-aligned-optimization,规范版本 7e00a2a9b8e0ee72df7173b90ba06384027e53a7:

  • Locate the cost before selecting an abstraction:已定位同步的重复全量 IO;拥有的离线目标经 Pyinstrument 5.1.3 观察,再用未插桩的相同工作负载对照,未把 profile 样本权重当延迟。
  • Share contracts, qualify implementations:复用既有 source_controls,不建缓存 owner 或线程;本次实际后端为 File Chat journal,没有更改 SQL authority。
  • Qualify the intended outcome:完整历史三组交替测量保留43条候选路径,base的11条既有语义用例和head的12条通过;新扫描断言在旧实现两次失败,均为3次读取而不是1次。
  • Keep the delivered boundary honest:本次只交付原恢复发现的局部改进,保留完整生产延迟与上游可用性的缺口。

关键代码讲解

  1. _context_recovery_plan,第97行 保持 binding/source/command/created_at 的筛选,只有发现模式改用扫描已有列表。没有提供 discovery_reads 的普通准入继续读取 self.pending;错误类别不是 antigravity_step_error 时原逻辑不变。
  2. context_recovery_observer,第317行 每次建立新观察,已存在的 source_controls 在第一次需要时读取完整请求。新增回归在旧观察之后提交后续输入,再启动新观察,最后走真实 reconcile_request;原失败与事件保持,未重复调用原 Argon 业务。

tests/test_lark_private_conversations.py 扩展原有用例,保持真实 Core、typed planner、队列、失败文件与发送回执断言,仅模型与远程provider使用合成服务。最初测试还假设新发现应完全排除候选,以及把独立/status读取也计入缓存读取;这两个错误 oracle 已按实际“可继续只读观察、禁止再执行业务”的合同纠正,原失败保留,最终12条通过。未删除业务不重放断言或放宽时限。

对主干的风险 / Risks

未发现阻断性问题。最强反例是扫描后出现纠正,新发现列表曾经无此消息;用例证明旧观察仍可作为候选提示,实际恢复准入则拒绝派发。source stop、新来源、没有额度、native tool未知效果以及成功后重复进入都保留现有保护。默认改变已在PR说明披露:同一发现共享观察,下一次发现及实际准入重新读;没有新增 opt-in 或隐含权限。

PASS:12条head用例、11条base语义对照、全历史43路径对照、编译和standard premerge(6项直接检查、2项选择检查)。FAIL/非阻断:base与head同样存在 interaction_contract 的 _admitted_interaction_next_cli_actions 维护性advisory,错误身份与细节一致,模块未被本PR修改;没有调整阈值。按当前Goal策略不查询或等待CI。CQR策略为disabled,不能把它说成已取得质量认证。

我的整体评价 / Verdict

这是 justified_increment;long_horizon preserved,user_experience improved,限定于已测同步发现成本。选择复用现有扫描观察,而不是增加全局缓存、时间预算或第二发现线程,能够直接减少已测重复 IO 并保留原准入边界。当前 PR 只修改 later-input 的发现读取来源,并扩展既有原 worker 回归;实际恢复仍读新事实,历史发送和失败记录继续保留。原始失败/历史和后续恢复路径没有删减,实际准入继续使用当前事实。默认扫描观察的一致性时点发生有意变化,完整路径的共同语义与新输入后的拒绝均有对照;不声称全部并发状态等价。没有协议版本或词汇新增,也不需要新兼容层。

检查了原 Chat/Lark 返回调用链,本 PR 没有渲染、排版、交互或必需用户步骤变化。没有宣称新的全页视觉验收或生产并发延迟达标。普通用户从原消息到可用结果不增加确认、复制或导航步骤。实际服务采用、长时间运行和所有欠答分别保留验收;这个有界改动易回滚且无需数据迁移,适合按既有授权合并。

English verdict: APPROVE 7e99d13; reuse the existing discovery-only source inventory, with fresh admission preserved. Local real-path controls pass; production latency and remaining backlog acceptance stay separate.

@loopx-agent
loopx-agent merged commit 817dd24 into main Nov 5, 2026
19 of 34 checks passed
@loopx-agent
loopx-agent deleted the codex/recovery-discovery-control-read-20261106 branch November 5, 2026 20:29
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