Skip to content

perf(kernel): read the steward endpoint vocabulary without the chat layer - #7746

Open
cocolord wants to merge 1 commit into
mainfrom
codex/steward-endpoint-leaf-20261031
Open

cocolord wants to merge 1 commit into
mainfrom
codex/steward-endpoint-leaf-20261031

Conversation

@cocolord

Copy link
Copy Markdown
Collaborator

Summary

steward_executor_endpoints() called importlib.import_module("loopx.chat_manager") only to read MANAGER_ENDPOINT_KINDS. Machine-configuration validation runs on the status, heartbeat-prompt, quota should-run and refresh-state paths. As a result, every heartbeat Turn loaded loopx.chat_manager, loopx.chat_agent and loopx.chat_store, even though none of them opens a chat channel.

This PR moves the endpoint and executor-kind vocabulary next to the namespace that validates it:

  • loopx/capabilities/steward_executor/machine_defaults.py now defines the following names, with the same values and comments: MANAGER_ENDPOINT_MANAGED, MANAGER_ENDPOINT_INDIVIDUAL, MANAGER_EXECUTOR_KIND_INDIVIDUAL, MANAGER_EXECUTOR_KIND_MANAGED and MANAGER_ENDPOINT_KINDS. Its only new import is the existing control_plane.turn_driver.host_binding leaf, which already owns MANAGED_TURN_HOST and EXECUTOR_KIND_MANAGED. steward_executor_endpoints() now reads the dict directly.
  • loopx/chat_manager.py imports those five names from the namespace and re-exports them by identity, so existing from loopx.chat_manager import MANAGER_ENDPOINT_MANAGED callers, tests and smokes keep working.

Endpoint values (codex, dsh), validation error messages, the shipped steward default, channel resolution order, authority, scheduling, settlement and output contracts are unchanged. No new top-level module is added: the loopx/ module budget stays pinned.

Measurements

These are fresh-process probes through loopx.entrypoint on a synthetic SQLite fixture, run against the exact base 04c5799b8 and this head. mods counts imported loopx.* modules. Wall times are medians of 6 alternating runs after one discarded cold run.

Route Base mods Head mods chat stack loaded Base median Head median
heartbeat-prompt --thin --codex-app 353 277 base yes, head no 1.21 s 1.08 s
quota should-run --codex-app 569 535 base yes, head no 2.28 s 2.22 s
status 414 368 base yes, head no 1.47 s 1.46 s
refresh-state --dry-run 475 450 base yes, head no 1.72 s 1.66 s

The call itself, measured in isolation, accounts for the module difference:

steward_executor_endpoints() in a fresh process Base Head
median latency 755 ms ~0 ms
loopx.* modules it adds 242 0

Read the whole-command wall times conservatively. Each route also pays its own authority reads and the Node effect-runtime round trip. For should-run, status and refresh-state, part of the removed graph is imported by other owners on the same path. So only heartbeat-prompt shows a wall-time gain clearly above run-to-run noise. The module counts and the absence of chat_manager/chat_agent/chat_store are deterministic.

Tests

tests/test_cli_entrypoint.py adds 5 cases. All 5 fail on the base and pass on this head:

  • test_steward_endpoint_vocabulary_is_read_without_the_chat_layer checks two things:
    • steward_executor_endpoints() and normalize_steward_executor_machine_defaults() return {"codex", "dsh"} and accept dsh without importing loopx.chat_manager, loopx.chat_agent or loopx.chat_store;
    • all five names exported from loopx.chat_manager are the identical objects defined by the namespace.
  • test_heartbeat_chain_routes_do_not_load_the_chat_layer covers heartbeat-prompt, quota should-run, status and refresh-state --dry-run. Each run uses a canonical SQLite fixture and must succeed with ok: true without loading loopx.cli or the chat stack.

Validation

  • Focused suites: 401 passed, across these files:
    • tests/test_cli_entrypoint.py;
    • tests/test_manager_channel_binding.py;
    • tests/test_chat_machine_configuration_api.py;
    • tests/test_chat_manager_{context,details,inspection,model_adoption,report}.py;
    • tests/capabilities/test_{capability_configuration_ui,machine_configuration_contract,machine_configuration_goal_defaults,steward_executor_machine_defaults}.py;
    • tests/test_native_steward_{runtime,managed_mode}.py;
    • tests/architecture/test_{top_level_module_budget,control_plane_import_boundaries,package_kernel_import_ratchet}.py.
  • examples/loopx-steward-channel-binding-smoke.py: passed.
  • ruff check on the three changed files: passed. The re-export carries # noqa: F401, following the existing retained-import convention.
  • The diff-scoped semantic advisory (scripts/generate_semantic_inventory.py --changed-from HEAD) found no new vocabulary carriers. The existing vocabulary moved; it was not extended.
  • loopx canary premerge --from-git-diff --git-diff-base origin/main: passed.
    • 6 direct checks and 2 selected catalog smokes (maintainability ratchet, semantic vocabulary drift).
    • 0 failures, 0 warnings, 0 manual holds, on surface python.
    • One earlier run failed for an environment reason only: semantic-vocabulary-drift-smoke.py needs the TypeScript dev dependencies. It passed after a local npm ci --ignore-scripts.

Follow-up and future-facing pass

  • Applied: the steward namespace and the channel now read one vocabulary owner. The lazy importlib cycle-breaker is gone, because the namespace no longer depends on the module that resolves through it.
  • Unnecessary: changes to configuration_ui.py and allocation.py. They already go through steward_executor_endpoints().
  • Deferred: the remaining heartbeat-chain import cost is in the routes' own owners (quota admission, status projection, effect runtime). Each should move only with its own parity tests.

Runtime self-merge is not requested; this needs ordinary review.

…ayer

steward_executor_endpoints() imported loopx.chat_manager only to read
MANAGER_ENDPOINT_KINDS. Machine-configuration validation runs on the
status, heartbeat-prompt, quota should-run and refresh-state paths, so
every heartbeat Turn loaded chat_manager, chat_agent and chat_store.

Move the endpoint and executor-kind vocabulary beside the namespace
that validates it and re-export every name from chat_manager by
identity. Values, error messages, defaults and authority are unchanged.

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.

动机 / Motivation

受影响的是只需验证steward执行端点配置的短生命周期CLI进程。以前读取端点合法值会导入整个chat manager;本项让配置与chat从同一轻量所有者读取词汇。已验证机器配置和manager channel在默认、显式端点与拒绝路径使用一致词汇。本项不改变默认执行端点、计费归属、凭据授权或调度策略。

这次判断绑定PR #7746的完整head aa916c0。评价对象是已经存在的实际调用任务与局部可观察结果;重复调用带来的成本或错误恢复路线是本项动机,不能把较小响应或更少导入直接等同于长期任务质量。

改动思路 / Approach

将现有五个端点/执行类别常量移到steward配置模块,chat保留同名重新导出,已存在的host binding仍提供managed词汇。本 PR 的合理边界是现有端点词汇的单一归属与导入闭包,不引入第二份枚举或新的endpoint registry。

沿入口跟踪到原所有者、返回值和失败恢复后,这个实现仍在现有边界上处理问题。无改动会保留原成本或错误指引;另起一套业务规则、持久化状态或通用缓存会增加同步义务,此处没有这类必要性。新增说明和投影应服务原调用方完成任务,不能改变原来的准入、权限、结算或来源完整性要求。

具体改动 / Changes

关键代码讲解

  • steward_executor_endpoints:直接从本模块唯一映射返回允许端点,不再反向导入chat manager。 输入与拒绝分支沿用现有调用路径;这一处的返回内容或依赖时机改变,不把局部投影提升为新的业务判定。
  • manager_channel_binding:继续使用重新导出的同一映射推导执行类别,默认和凭据边界不变。 输入与拒绝分支沿用现有调用路径;这一处的返回内容或依赖时机改变,不把局部投影提升为新的业务判定。

端点和值域逐项搬移,默认端点仍由原channel resolution决定;不依据凭据存在自动切换执行端点。正向场景是:合法端点配置与manager channel选择保持一致,个人和managed执行类别仍分开。负向场景是:非法端点、未授权凭据组合与配置拒绝仍由既有所有者处理。这些是依据实际源码与已有调用测试核对的行为边界;失败和恢复继续由原owner负责,没有以返回字段存在代替真实状态读取。

规范依据为原公开调用行为、既有所有者和相应回归;已检索改动路径与周边文档,没有为这次局部性能/适配修正找到另一个已接受专项RFC。作者的量测叙述不充当独立功能合同。

实际验证 / Validation

steward machine defaults与manager channel binding共37项测试 PASS;Python编译与 diff hygiene PASS。

执行命令:python -m pytest -q tests/capabilities/test_steward_executor_machine_defaults.py tests/test_manager_channel_binding.py。本轮统计只包含上述实际执行;作者PR内微基准、旧head完整回归和旧review的历史量测都已阅读,但不冒称本轮重新执行的结果。

对主干的风险 / Risks

端点和值域逐项搬移,默认端点仍由原channel resolution决定;不依据凭据存在自动切换执行端点。最需要防止的情况是:非法端点、未授权凭据组合与配置拒绝仍由既有所有者处理。已核对相关调用方和已有review,未重复发布旧head意见;本轮对新增head的源代码与局部回归单独作判断。原持久化状态和业务所有者保持,仍然不能由小范围通过推断整仓或所有部署入口已经合格。

当前精确head失败证据:test-shard (5)、dashboard-browser (2)。当前test-shard失败及取消未获得可读日志;dashboard时间预算失败也仍需当前来源绑定的归因,不能只因文件不相交就宣布全部无关。 未取得的分片日志明确留作未知;同名错误或改动文件不相交都不足以建立pre_existing归因。

最小补齐是针对当前实际失败取得日志,并提供不可变base/head同命令同条件归因,或能独立覆盖该失败不变量的当前真实入口证据。已完成的聚焦回归不应无条件重做,也不要求无关功能重写;如果归因确认是回归,再修相应最小代码路径。未完成的检查不是单凭pending就要求改代码的理由。

我的整体评价 / Verdict

REQUEST_CHANGES:当前阻断是具体的验证证据缺口。聚焦审查尚未发现可复现的阻断性生产代码缺陷,不能把未归因红灯写成代码finding。 审查仅适用于exact head aa916c0。

本 PR 的合理边界是现有端点词汇的单一归属与导入闭包,不引入第二份枚举或新的endpoint registry。 已验证机器配置和manager channel在默认、显式端点与拒绝路径使用一致词汇。 已检查 loopx/capabilities/steward_executor/machine_defaults.py:steward_executor_endpoints;loopx/chat_manager.py:manager_channel_binding;变更是CLI/内部读取或文本协议,没有修改浏览器页面布局,视觉截图不适用。

当前test-shard失败及取消未获得可读日志;dashboard时间预算失败也仍需当前来源绑定的归因,不能只因文件不相交就宣布全部无关。 本项不改变默认执行端点、计费归属、凭据授权或调度策略。所有本轮探针使用合成fixture,没有运行真实模型任务或发起业务作业;本review陈述审查与验证事实,不声称已经发布部署或完成合并。

English verdict: REQUEST_CHANGES — exact head aa916c0. Focused code review and the listed local regressions found no confirmed blocking implementation defect. Approval is held for the named current validation gaps; resolve their source-bound evidence rather than changing unrelated code.

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