Skip to content

perf(machine-configuration): load builtin namespace owners on first resolution - #7756

Open
cocolord wants to merge 1 commit into
mainfrom
codex/should-run-import-closure-20261031
Open

cocolord wants to merge 1 commit into
mainfrom
codex/should-run-import-closure-20261031

Conversation

@cocolord

@cocolord cocolord commented Oct 31, 2026 •

Copy link
Copy Markdown
Collaborator

Delivery brief

  • Goal/source: runtime-composition kernel direction (load owners on demand, keep the heartbeat guard path small). This change narrows the quota should-run import closure.
  • Current gap: should-run builds the builtin machine-configuration registry only to read the context_delivery setting. Each build imported all ten capability owners and validated every template. That included the explore mode plan, which goes through a TypeScript effect-runtime request.
  • Observable result: builtin owners load the first time their namespace is resolved. A guard that reads only context_delivery no longer imports or validates the other nine owners.
  • Owning boundary: loopx/capabilities/machine_configuration/ (generic MachineConfigurationRegistry plus the builtin composition table). Authority, scheduling, settlement, defaults and output contracts are unchanged.

Change

  • MachineConfigurationRegistry.register_deferred(namespace, load):
    • Reserves the namespace id. Eager and deferred owners share one duplicate check, and the namespace id is validated.
    • On first resolve(), loads the owner, rejects an owner that declares a different id, then runs the same public_descriptor() template validation as register() before caching it.
    • Unknown namespaces still raise unsupported machine-configuration namespace.
  • namespace_ids includes deferred owners. public_catalog() resolves, and so validates, every owner.
  • build_builtin_machine_configuration_registry() registers the ten builtin owners from one table, in the original order, as deferred owners.

Behavior notes for review

  • Fail-closed reads are unchanged: normalize_machine_configuration still resolves and normalizes every namespace present in a stored document, so an invalid or unknown stored namespace still fails the read (covered by a new test).
  • Changed timing: a broken template or owner import in a builtin namespace now fails when that namespace is resolved, or on public_catalog(). Before, it failed on every registry build. This affects only builtin owner code defects, not user data. Every catalog, settings and API path resolves all owners.

Validation (exact head bfc821121)

Check Result
tests/capabilities/test_machine_configuration_contract.py 18 passed. New tests: lazy load-once, deferred template rejection, mismatched owner id, shared reservation and invalid id, builtin catalog order, invalid stored sibling fails closed, subprocess import-isolation for a context_delivery-only read.
Test files that reference machine configuration (41 files) 1413 passed, 15 skipped
tests/test_cli_entrypoint.py 99 passed
ruff check (changed files) passed
Diff-scoped semantic advisory (generate_semantic_inventory.py --changed-from HEAD) 0 candidates; no new vocabulary
loopx canary premerge --from-git-diff --git-diff-base origin/main (standard tier) passed: 5/5 canaries, 0 manual holds

On the premerge run: the first attempt in a fresh worktree failed semantic-vocabulary-drift-smoke because npm dev dependencies were not installed. After npm ci --ignore-scripts it passed. The failure was environmental; no code changed between the runs.

Measurement

Setup:

  • quota should-run on a disposable copy of a real registry and runtime. No live state was touched.
  • Warm bytecode, one warm-up round, then 16 paired runs with alternating order and unique turn ids per run.
  • Wall time is the subprocess wall time; in-process time is the entrypoint.main duration.
Baseline Wall median (p95), base → head In-process median, base → head Loaded loopx modules Distinct .pyc opens
origin/main 04c5799b8 2.044 s (2.095) → 1.966 s (2.081) 1.994 → 1.917 s 563 → 546 666 → 645
Local merge with #7739, #7741, #7746, #7748, #7749, #7755 1.400 s (1.443) → 1.326 s (1.390) 1.355 → 1.284 s 508 → 490 611 → 589

What the profile shows:

  • apply_context_machine_options drops from 0.714 s to 0.098 s, and the explore mode plan request (0.53 s) leaves the guard path.
  • Most of that profile delta is a shift, not a saving: the one-time per-process effect-runtime fingerprint moves to the next TypeScript caller. That caller is a turn-start hook, and perf(effect-runtime): reuse a private source digest across processes #7748 addresses the fingerprint cost.
  • The net end-to-end saving is about 75–80 ms per should-run (≈4–5%), plus 17–18 fewer modules. The guard also no longer depends on the explore planner to read an unrelated setting.

Output parity:

  • Normalized should-run JSON (timestamps, digests and opaque tokens masked) is identical between base and head.
  • The only remaining difference is staleness_seconds (0 vs 1), which varies between two base runs as well.

Scope decision: broad module deferral

I also ranked the other loaded-but-unused import subtrees at the combined heads. Together they cost about 0.24 s warm, spread across 123 roots, and the largest single root is about 18 ms. I deferred that work: a broad lazy-import sweep would touch many owners for little gain per change. The machine-configuration registry was the one concentrated cost on this path.

Limits

  • Not measured on the File provider separately; this change does not touch storage.
  • Not installed into any live runtime.
  • Merge needs maintainer authorization: loopx/** runtime surface.

…esolution

The builtin machine-configuration registry imported and validated all ten
capability owners on every build. should-run builds it to read the
context_delivery setting, so each heartbeat guard paid for the explore
mode plan (a TS RPC) and the other owners' templates it never reads.

Register builtin owners as deferred: the registry keeps every namespace id
and loads an owner, checks its declared id and validates its template the
first time that namespace is resolved. Stored documents still normalize
every namespace they contain, so an invalid or unknown stored namespace
still fails closed; public_catalog still validates every owner.

Signed-off-by: lusendong.6789 <lusendong.6789@bytedance.com>
Co-authored-by: TRAE CLI <traecli@bytedance.com>

@songoow songoow left a comment

Copy link
Copy Markdown
Collaborator

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

REQUEST_CHANGES — 当前 required 验证有尚未归因的失败,暂缓批准。没有新确认的阻断性代码缺陷。 精确 head:bfc821121c09417c8cc7fda33c8934047a74aec7。

动机 / Motivation

这项修改影响只需读取一个本机设置的 heartbeat guard 使用者,以及通过机器设置目录查看或编辑全部能力的操作者。

此前只读 context_delivery 也构建全部十个 namespace owner并验证每份模板,连带触发 Explore planner;现在首次 resolve 才加载目标 owner,完整 catalog 仍逐一加载全部 owner。

本轮确认延迟注册、模板校验、未知 namespace与损坏 sibling fail-closed行为;相关本机设置与hook断言通过,当前浏览器分页恢复验证及独立端到端A/B仍有缺口。 本 PR 不改变机器设置默认值、配置事务、授权、调度或结算,也不把已保存偏好当作宿主就绪或启用证明。

剩余缺口:同一 fixture 的不可变基线 rows:56/call:152 超时、当前 head 一次完整通过已经完成,report-window 后的 13 行读回、source 恢复和只读 receipts 已验证。剩余最小补证是结合原 CI 失败与该配对,核对 Node/Chromium、并发负载及快照改变与父消息刷新时序,说明仍有风险的间歇性条件;只补尚未覆盖的条件和完整调用分支,不重复已经通过的 smoke。

改动思路 / Approach

加载时机属于 builtin composition 与 registry 的局部职责;复用原 owner 和 public_descriptor 验证,比删掉校验或维护第二份轻量配置定义更稳妥。 本次交付按需加载与同一模板校验,不改变公共schema和事务;unused owner代码缺陷的报错时间由每次构建推迟到resolve/catalog,已明确披露。

从调用链看,quota context-machine options、machine-config CLI以及chat/settings API创建builtin registry并resolve所需namespace或public_catalog。 输入来自原十个 capability-owned namespace定义及真实machine/configuration.json;没有新增用户配置字段。 通用 registry负责唯一id与加载校验;各namespace owner仍负责normalize/project/update,store仍负责事务。 相同十个 factory保留唯一owner;通用contract不导入capability实现。只有解析时机改变,stored-envelope normalize仍检查所有提供的namespace,不因未用sibling而忽略损坏。 因此这是一项有实际消费者的有限优化,不需要增加用户的配置、确认或恢复步骤;量化的完整任务收益仍要依赖可比较的真实入口测量。

具体改动 / Changes

关键代码与合同

本轮按基线 04c5799b88f6c4cf12a224b7fa679f272e1e794e 的 docs/reference/required-work-context.md 阅读既有合同,映射 Machine default,再核对当前实现与消费者;新增文档不充当自己的独立验收标准。完整差异共 3 个文件,+284/−70,生产、测试与文档分别检查,没有代码搬迁掩盖的第二个决策所有者。

  • _reserve / register / register_deferred:对eager与deferred owner统一防止重复占用。新loader不立即import,但namespace id先验证并预留。关键条件是duplicate id cannot be registered through either path,结果交给 resolve/namespace_ids。

  • resolve:只加载所请求owner并保留原校验门。验证实际id及public_descriptor后才缓存;失败保持loader。关键条件是no invalid template returned as usable owner,结果交给 normalize/project/preview/apply/catalog。

  • namespace_ids / public_catalog:所有namespace仍可发现,catalog会完整校验。ids合并两种注册;catalog通过resolve逐个取descriptor。关键条件是catalog order remains sorted and complete,结果交给 machine-config describe and settings/API。

  • build_builtin_machine_configuration_registry:在composition边界登记原十个factory。创建registry不再import全部owner;首次需求加载。关键条件是same owner table, no duplicated normalization,结果交给 context_machine and machine-config CLI。

PR body Behavior notes明确区分“损坏用户数据仍立即拒绝”与“未用owner的代码/template缺陷延迟至resolve/catalog”。 本轮检查了完整 diff 和变更文件之外的实际消费者,未发现应单独报告的确定性代码回归。

验证记录

PASS:pytest -q tests/capabilities/test_machine_configuration_contract.py,18 passed in 1.82s (isolated socket-capable run)。负例覆盖:模板、重复id、错误owner与stored sibling新旧negative测试均通过;不因lazy registration忽略用户数据损坏。

关联验证的完整边界:API/default/context suites: 73 passed, 5 skipped, 5 failed due literal loopx executable missing from PATH. Re-running only those 5 with venv PATH: 5 passed, 36 deselected; session exited 1 because default-route leak guard observed a parallel/shared path creation. No test assertion failed on the corrected PATH run. ruff/compile/diff check passed.

默认 sandbox 的本地 Effect socket 权限失败已作为环境观测保留;在允许本地 socket 的独立临时环境中运行相同测试,不修改代码或降低断言。当前原始 CI 快照为 failure=2, pending=6, skipped=5, success=26,跳过不等于通过,聚合 checks failure不重复计为另一独立故障,pending也不单独构成阻断。

补充真实入口与浏览器配对

完整catalog、空配置、context off/on、unknown sibling与malformed sibling六组,exit及完整JSON逐项一致,不需要归一化;前四组exit0,两个损坏sibling均exit2且完整错误输出一致。最初用了不受支持的runtime-profile别名,双方均exit2;该次setup误差已保留,后续以文档中的--codex-app重跑。

补充实跑(Linux / Node 24.22.1 / Chromium 138,临时构建的packaged Chat,真实SQLite/Inbox):不可变基线 04c5799b88f6c4cf12a224b7fa679f272e1e794e 复现同一 rows:56 / call:152 的30秒超时;当前head整条delegation-search smoke在28.95秒通过,包括report-window后的13行读回、source拒绝/恢复、键盘焦点与只读receipt检查。两侧使用同一份新构建UI;已核对其源码在base/head无差异,Python backend分别绑定相应checkout。原CI失败和本轮head一次通过均保留,不能只选成功或宣称历史竞态已修复;跨CI环境的间歇性解释仍不足。

对主干的风险 / Risks

当前验证缺口 — chat-bundle-browser (1)。 delegation-search-browser-smoke.mjs rows:56 / call:152: page.waitForFunction Timeout 30000ms exceeded。日志中前面的28个chat browser场景及其他acceptance通过,但 delegation-search 在第152行等待13行超时。它是当前head的独立失败,先前成功场景不能证明这个分页/快照恢复条件。

最小补齐:同一 fixture 的不可变基线 rows:56/call:152 超时、当前 head 一次完整通过已经完成,report-window 后的 13 行读回、source 恢复和只读 receipts 已验证。剩余最小补证是结合原 CI 失败与该配对,核对 Node/Chromium、并发负载及快照改变与父消息刷新时序,说明仍有风险的间歇性条件;只补尚未覆盖的条件和完整调用分支,不重复已经通过的 smoke。 已在隔离的本地浏览器环境完成下面的有界配对;没有凭修改文件不相邻、一次成功或其他PR相似失败就将它归为无关。这里要求的是覆盖这个已观察条件的证据,不要求盲目改代码、删除断言或放宽冻结阈值。

代码层最强回归路径是:lazy加载意外推迟真实存储数据验证,损坏sibling被忽略,或catalog丢失未加载owner。 当前由normalize_machine_configuration遍历全部stored namespaces并resolve;public_catalog遍历合并后的namespace_ids。 相关局部证据为上述测试;未独立重做作者真实runtime的16组A/B;量化收益保留为作者证据。Python测试的默认route守卫观察可能来自同机并行checker,不构成已证实的本PR写路径回归。

我的整体评价 / Verdict

设计边界和代码规模与重复调用成本相称,现有 owner 得到复用,局部正反例提供了有用支持。但当前失败的不变量尚未有充分归因或当前反证,本轮已完成下面有限的同fixture public-entrypoint 基线/当前head观察,但尚未覆盖完整调用分支与public-path mutation反事实,所以这些证据保持 UNVERIFIED;不把作者A/B或测试数量写成本轮已证明的长程收益。加载时机属于 builtin composition 与 registry 的局部职责;复用原 owner 和 public_descriptor 验证,比删掉校验或维护第二份轻量配置定义更稳妥。 本次交付按需加载与同一模板校验,不改变公共schema和事务;unused owner代码缺陷的报错时间由每次构建推迟到resolve/catalog,已明确披露。

检查了machine-config CLI、context_machine和chat/settings API的加载调用;本 PR不改变设置页面内容或交互,视觉审查不适用。 已实跑上述浏览器断言;该变更无新页面视觉设计,本轮未独立逐张审美或全页排版审查。CI与本地浏览器环境不同,不能认证其间歇性已消失。 这项 review hold 与 pending CI、merge授权分别判断;补齐具体证据后可重评同一head,无需为了review形式制造代码改动。

English verdict: REQUEST_CHANGES bfc821121c09417c8cc7fda33c8934047a74aec7. Focused code tests support the implementation, but the current chat-bundle-browser (1) failure remains unresolved. No new blocking production-code defect is established; assess the remaining risk-relevant CI/local differences and intermittent triggers while retaining the completed paired scenario evidence. Bounded public CLI pairs agree; complete public-path counterfactual coverage and current CI attribution remain unverified.

This branch has not been deployed

No deployments
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