Repository navigation
Conversation
Signed-off-by: Lihua <1017343802@qq.com>
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; reasoning_effort=xhigh
动机
维护者在从源码构建 wheel 后运行冷源恢复验收,需要创建备份的子进程与父测试读取同一份产品源码。 原来父进程读 checkout、临时目录中的备份子进程却读已安装 wheel,14 个恢复场景在源码身份断言处提前失败,尚未验证导入和历史保留;现在只把原生产者子进程绑定到父包根目录,独立复制的冷接收端仍使用自己的包。 本轮在真实隔离 wheel 与 checkout 混合环境复现 base 的14 failed/4 passed,新 head 原模块18项全部通过,原源码身份和恢复断言均保留。 范围只修复此测试模块的来源绑定,不改产品恢复规则、不证明整套 Stage2c 或 Windows 已合格,也不关闭 #5280 的其余验收。
改动思路
在原 backup helper 的一次 subprocess.run 上显式绑定来源,保留原来源断言,比删断言或全局修改 PYTHONPATH 更合适。原生产者和冷接收端是两个有意不同的测试角色;只修前者,不把已经退休的 Python 生产者带回接收端,也不重写恢复决策 owner。
具体改动
精确 head 0bab19d5e77f36c6129f37d26440a2489905aee4,base 233cc76fd22760947d73e1501032b8b77e28148b,完整 diff 只有 tests/control_plane/test_cold_source_disposition_e2e.py:112-134 的 +10/-1。由已导入的 loopx.file 得到 resolved parent source root,以 os.pathsep 放在继承的 PYTHONPATH 前面,其他环境、sys.executable、命令参数、超时及断言均保留。
按不可变 233cc76fd22760947d73e1501032b8b77e28148b 的 docs/development/testing-and-quality.md、Local Validation Environment 核验解释器及 imported checkout 的来源要求。实际 Stage2c workflow 构建并安装 wheel 后从 checkout 跑 pytest;原 backup 在临时 cwd 启动,而其他原 fixture 入口在 checkout cwd 运行,因此原来源差异确实存在。cold_cli 仍独立绑定复制包并读回它的 init.py;其四个正常 Python producer 文件仍删除,TS/File/SQLite 决策 owner 未改变。完整模块中 helper 前后其他字节一致,恢复、活租约拒绝、未证明 capture 拒绝、later write、原 receipt/archive 保留及 replay 断言未减。
对主干的风险
最强反例是仅在 editable 安装里取绿,或把冷接收端也绑回正常源码。我先从当前源码构建真实 Chat 资产和 wheel,在隔离选定解释器中以 wheel 替换 editable;独立读回父进程分别导入 base/head checkout,而临时 cwd 的普通子进程确实导入 site-packages。相同完整模块和解释器在 baseline14 failed/4 passed,14项全部止于原 line121 的来源断言;head18/18通过并实际执行原冷接收端与File/SQLite后续恢复断言。Ruff、source check0errors/0warnings及diff-check通过;advisory无支持的changed carrier,不证明所有动态语义。
最初 wheel build 因未准备生成的 Chat 资产失败,补建原源码资产后重建成功;首次两版 pytest 因我指定的 basetemp 父目录未创建各18个setup error,保留原失败后仅建该父目录,完全相同命令再运行得到上述对照。没有改产品断言或放宽阈值。环境是macOS/CPython3.14.8/Node24.21.0,未独立执行Ubuntu3.11、Windows、整套Stage2c或打包App,CI未查询。当前批准只覆盖已验证的模块修复,不关闭 #5280 的其他问题。
我的整体评价
无阻塞发现,此 helper 的来源修复达到有界目标。不可变源搜索与同作者6062/6063/5280/5248批次检查显示,它恢复已有实用验收,没有新增重复测试或框架。未来重构检查认为保留原生产者局部 env 与冷接收端独立边界更清楚;邻近 temporary-cwd helper 的 wheel 资格没有借此宣称通过。变更小、可逆,APPROVE 此精确版本。
English verdict: APPROVE - head 0bab19d. A real isolated wheel/checkout environment reproduces14 baseline source-identity failures and passes all18 unchanged cases at the head. Only the original backup child is bound to the parent's source; the separate copied cold receiver, provenance assertions and File/SQLite recovery/history boundaries remain intact. Initial missing build assets and reviewer temporary-directory setup failures are retained and corrected. Broader Stage2c,Ubuntu3.11,Windows and PR5280 qualification remain separate; no CI consulted or merge authority granted.
Superseded by PR #6040. Its approved exact head passes
stage2c (e2e 2)while preserving the job's installed-wheel original-producer path. This PR would force that child onto checkout source and narrow installed-wheel coverage, so it is closed in favor of #6040.The Stage2c Linux job installs a wheel and runs pytest from the checkout.
backup()launches its original-producer CLI from a temporary workspace, so that child imports the installed wheel while its parent imports the checkout. Fourteen parameterized cold-source cases then fail at the source-identity assertion before exercising recovery. This superseded variant bound the original child to its parent's source root throughPYTHONPATH; the cold receiver separately used its copied package.Validation on latest
mainat233cc76fd: the representative case failed before this change and passed after it; the full cold-source disposition module passed 18/18. Ruff and the public-boundary scan passed. Risk-based premerge passed its diff/compile checks (no catalog canaries selected). This is a separate CI qualification repair for PR #5280 and does not address its Windows runtime-write failure.CI at head
0bab19d:stage2c (e2e 2)andwindows-powershellpassed.test-shard (2)failed four Todo/Lark cases with the same test names and failure messages as the shard 2 artifact on PR #6062.test-shard (4)failed six Goal-acceptance/Lark cases with the same test names and failure messages across both PRs. The Stage2c test-source change does not touch those tests or their owners. These results remain as comparison evidence; #6040 is the active repair.