Repository navigation
fix(accounts): verify worker and steward relay readiness separately - #8394
Conversation
Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
…robing 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
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
动机 / Motivation
原生账号扩展会在工作 Agent 的线路正常、已配置的管家线路拒绝凭据时仍给出安装通过。基线用同一个本地 relay 复现了这个结果。按 packages/loopx-codex-provider-routing/NATIVE.md 在 aa475b29f1976a4fde901deca84672ddb3415152 的原合同验收:NATIVE-LIFECYCLE-1 未启动或未配置可选线路时保持可安装;NATIVE-LIFECYCLE-2 已配置线路或运行实例不匹配时不通过;NATIVE-LIFECYCLE-3 使用既有排空边界;NATIVE-LIFECYCLE-4 原消息回传另验。
影响已安装原生账号扩展的操作者,以及调用其 doctor 的 LoopX 扩展安装器。同一个本地 relay 上,仅更换配置中的管家凭据:原来仍通过,修复后管家标为不可用。
通用扩展自检拒绝通过,工作 Agent 的线路仍照常报告其独立状态。没有改变账号策略、触发模型调用、重放业务或修通用安装器的目录传递。上线时仍需让现有消费者采用同一个已验证版本,并独立验收实际消息结果。
改动思路 / Approach
读取同一份现有配置,对工作 Agent 和管家分别发出经过认证的本地状态查询,再核对 build、PID 和 instance。保留原工作 Agent 的 relay 字段。未配置管家线路时沿用可选行为;配置存在但失败时,退出码使真正的扩展自检拒绝通过,工作 Agent 的线路仍照常报告其独立状态。
复用原有认证探测、relay 实例标识和排空锁。改动只覆盖原生账号 provider 的自检与显式接续。
具体改动 / Changes
精确头 af3db9eaa7e0e95bd25a098846a77878d0e8ca01,7 个文件,+158/−27。provider.doctor 消费两路状态;relay_lifecycle.consumer_statuses 复用原有认证探测;relay_lifecycle.reconcile 仍走已有锁与排空;openai_relay.consumer_token 在 HTTP 探测和排空前拒绝共享、空白或非法管家凭据。第一次复核还复现了非法字符会让状态只剩笼统失败;最终版保留了两路结果。
对主干的风险 / Risks
行为变化限于已配置线路的安装验收与原有显式 reconcile。安装包实测覆盖未配置、两路正常、单路过期、非法凭据与恢复;负例中工作 Agent 仍为 ready,通用扩展自检拒绝验证。不同实例、在途请求排空及坏凭据不触发排空也有对应检查。最终本地测试 221 项通过、4 项跳过;标准预合并与精确 diff 的公开边界扫描通过。按当前配置未查看 CI。
用已安装入口和隔离 relay 即可判断这次自检缺口;原服务采用与真实回传需另验。
我的整体评价 / Verdict
同一 provider 内的修复覆盖了已复现的错误,未扩大权限或改变原消息处理。上线后仍按原有职责验证服务和真实回传;安装包测试的作用仅限本地探测及版本归属。
English verdict: APPROVE — installed readiness is role-specific and fails closed for a configured broken route; the optional path and existing relay ownership are preserved.
The native account extension doctor could verify an installation when the worker relay was healthy and the configured steward endpoint rejected its credential. The doctor now checks both routes from the same configuration and verifies that successful replies describe the same relay instance. An unconfigured optional steward route still permits installation; a configured route failure is reported independently and fails verification without changing worker admission.
Explicit reconciliation now checks the configured steward route under the existing relay lock. A shared, empty, or malformed steward credential is refused before probing or drain. The original worker status field, permission checks, and message delivery boundaries remain in place.
Validation: the original false green and the malformed-credential loss of role status both reproduced. The final provider, extension, Codex authentication, managed service, and update activation tests passed (221 passed, 4 skipped). An isolated install of the final 0.15.4 wheel proved the real extension doctor detects stale and malformed steward credentials while reporting the worker ready, and verifies the same instance again after recovery. Standard premerge and the scoped public boundary scan passed.