Repository navigation
perf(chat): resolve history returns through original request receipts - #7939
Conversation
Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent; GPT-6; OpenAI; self_reported(当前 CLI 未取得会话执行身份,未声明精确构建版本)。
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
动机 / Motivation
管家会话的使用者打开包含异步结果的长历史时,会反复等待服务端寻找回传状态。原路径对每页枚举全局路由,其他会话积累的交办也会增加当前会话的读取成本。本次让已有原请求回执直接定位路由,减少重复读取,并继续展示完整正文和当前送达状态。完整 App 启动与实际安装后的性能仍需单独验收。本 PR 只交付服务端回传投影的有界优化。
改动思路 / Approach
HTTP Session 快照仍由现有 Chat owner 读取原 journal、冻结前缀并处理分页,再调用回传投影。新增的局部迭代器先从本页消息所属的原 Turn 取得 handoff receipt,即原交办的接收回执,随后进入原有的路由、来源主机及消息结果身份校验。回执只缩小查找范围,不能授权读取另一个会话。全部结果找到后停止;旧回执丢失或损坏时继续原来的完整查找。
这种放置保留了同一套状态解释和来源校验,也避免增加需要失效管理的路由缓存。最强的反对理由是:缺失回执的页面仍然慢,且新增一次原 Turn 读取。实测完整输出保持一致,普通页面确实减少了无关读取,因此保留现有投影 owner 内的这段局部逻辑是适度选择。当前 PR 的边界是减少回传查找成本,后续完整启动优化仍沿现有会话历史 owner 验收。
具体改动 / Changes
本次依据 docs/architecture/rfcs/app-conversation-and-async-inbox-v0.md,spec_revision 为 f941b5939345c6d1c3d770a982182624e7ef393f。以下是该文历史分页段落的逐条映射:history-prefix-integrity(原正文、顺序、冻结前缀不变)已实现并通过完整 HTTP 页面比较;original-source-projection(从同一原来源投影本页回传)已实现,外来主机和错误 Session 均不获得状态;read-only-recovery(只读提示、旧记录兼容且不重放模型)已实现,原回执丢失时仍可从原路由恢复状态。文档中的原生安装与双向媒体资格属于后续整体验收,不由本次源码结果替代。
关键代码讲解
project_chat_return_deliveries仍只给实际存在的回传消息附加送达读回。状态每次重新读取,未缓存已送达结论;无匹配时保留原消息。candidate_paths去重本页原 Turn,接受单条和多条回执中的合法请求标识。非法路径、损坏 Turn 或不匹配回执进入既有 fallback。局部集合仅在一次读取内存在。project_chat_session_snapshot仍是实际快照消费者,原分页、协作载体选择及 provider 回复上下文的合成顺序保持原样。
生产改动为一个现有 owner 内的候选路径迭代器;其余新增内容为回归测试。读取了 base/head 的相同调用链,并核对相关 #7878 的变更范围,未把另外一套全局索引或状态判定引入本次修复。
对主干的风险 / Risks
主要风险是错误地把提示当作授权,或为了加速漏掉旧回传。本轮通过实际 Session HTTP 接口及文件后端做了四种同输入 base/head 对照:正常回传、送达状态变化、原回执丢失和来源主机不匹配。各自全部页面的完整内容哈希相同,正文与顺序完整,持久化 JSON 未变。带 256 条无关路由的正常读取由 257 次路由读降为 1 次;丢失回执时两版都完整查找,来源主机不匹配时两版都不附加状态。该 HTTP fixture 仅把无活动 Turn 的 liveness hook 置为空操作,分页、回传投影、来源关联及文件状态都走真实实现,未调用模型或真实消息服务。
PASS:相关模块 94 项测试、Ruff、编译、RFC 双语与标准 premerge gate。FAIL 保留:maintainability ratchet 的 render_canonical_todo_sections 既有问题,在不可变 base 和本 head 上同命令的完整输出逐字一致;premerge 将其列为 inherited advisory。最初缺少 npm 开发依赖的检查已恢复环境后重新执行。两个定向回归在父版本失败,在本 head 通过。三组未插桩完整投影对照平均降低约 24%,只说明该服务端工作负载,不外推 App 端延迟或 p95。CI 按当前 Goal 策略未查询、轮询或等待。
我的整体评价 / Verdict
结论是可交付的有用增量(justified_increment)。long_horizon 保持原有历史、重试和持久化语义,同时减少会话积累后的重复扫描;user_experience 在这个服务端边界得到改善,用户无需重新提供信息或执行额外操作。visual_review 为 not_applicable:检查范围是 Session JSON 回传投影,渲染代码未改;unverified_scope 是实际原生 App 的安装后启动与响应性能,后续需单独读回。
兼容判断为 retain:持久化的旧回执缺失不能按未发生处理,因此完整 fallback 有明确用途。新增局部逻辑与已测成本相称,没有新增状态 authority、开关、服务或 actor 权限。共享词汇沿用现有回传状态,未产生新的业务判定。源码范围没有阻塞性发现;合并仍需新鲜的 exact-head readiness 和既有授权,完整管家恢复资格继续保留。
English verdict: APPROVE — head fc35010 preserves full HTTP readback and source isolation while avoiding irrelevant route scans; local validation passed with an unchanged inherited advisory.
打开有大量异步回传的管家会话时,每个历史页都会枚举所有会话的回传路由,再寻找本页的状态,重复的文件读取拖慢完整历史加载。
本次复用原 Turn 中已保存的单条或多条 handoff receipt,先读取对应路由;原 Session、来源主机和消息结果身份仍逐项校验。旧记录缺失、损坏或无法匹配时继续完整查找。每次读取都重新观察送达状态,历史正文、游标及持久化格式保持原有契约。
验证:
render_canonical_todo_sectionsmaintainability advisory,其底层检查仍失败;首次缺少 npm 开发依赖已恢复后重跑。主要风险是旧回执的兼容查找;完整 fallback 和原来源校验的回归用于约束该风险。实现沿用现有 Chat 回传投影 owner,没有新增缓存或运行服务。