Files
HomeAgent/internal/kernelboot/syncbus_test.go
JianFeeeee a68d6a428c feat: 模块化内核(编译期依赖图定序)+ 密钥防火墙 + 插件三态生命周期 (#10)
* feat(kernel): 模块化内核 + 编译期依赖图定序

把单体 init 序列拆成「模块自声明依赖 + 编译期生成依赖图 + 运行期只读图」。

## 为什么

原 cmd/homed/main.go 里 17 步 init 是**手写顺序**,依赖关系只存在于
注释和人脑里。实测踩到的坑(见 docs/zh/kernel-modularization-design.md):
 · nlp.defaultParser 被 initONNXParser 写、被 distiller 读,两者相距 60 行,
   只靠 ticker 10min 才没炸(隐式依赖,无声明)
 · 加一个模块要人肉找"该插在哪",插错的表现是运行期 nil 解引用
 · 关停是 defer ks.CloseAll(),而热更新路径 os.Exit(42) **跳过 defer**
   ⇒ docStore/distiller/textMem 的 flush 全部丢失(每次热更新都发生)

## 怎么改

- internal/kernelboot/:KernelState(一个结构体收全部包级共享变量,字段
  nil 安全)、Module 接口、graphfile(依赖图编解码 + 与二进制 hash 对账)、
  scheduler(按 BFS 层并行 Init)、syncbus(层边界写通知)、
  lifecycle(Quiesce/Resume 可逆伪关机,区别于一次性 CloseAll)
- internal/kernelmod/<name>/:每个模块一个文件夹,Requires/Provides 自声明;
  all/all.go 是唯一的 import 清单(Go 循环导入约束)
- cmd/homed-depgraph:编译期生成依赖图,Makefile 注入 digest
- 运行期只**读**图,不计算顺序(顺序是编译期决定的,源码里没有中央清单)

## 判据

kernelboot 8 条 + 图失败模式 7 条(全部拒绝并给准确错误)+ 模块目录数
与注册表一致性。变异测试 15/15 咬住,含:
 · 删掉 AddCloser 的锁 → -race 报数据竞争
 · Scheduler 同批跑去重 → 203 vs 200
 · 图 hash 不匹配 → 拒绝启动

## 顺带修的缺陷

热更新路径漏调模块关闭 ⇒ 显式 stopKernelModules(),并用 AST 判据钉住
"必须在 os.Exit 之前"(字符串检查在本仓已骗过我三次)。

实测:冷启动 1630ms(5 层/17 模块,原 17 步串行);生产 22 插件全部建链。

* feat(security): 密钥防火墙 + 配置加密 + close 纪律

## 密钥防火墙

模型只见别名、不见明文;插件工具调用入口(StageHost.ExecuteTool)做入向
回填。三维能力:
 · 出向:工具输出里的密钥被替换成 [[secret:name]] 别名后才进上下文
 · 入向:模型传别名,入口处填回真值(插件完全无感知)
 · 存储:config.db 里不存明文(0644 的库可读),敏感值独立 0600 文件

模式库「宁漏勿误伤」:宁可漏掉一次替换,也不把正常文本误当密钥。

## 配置加密

- internal/security/{codec,key,keyring,store,global}.go:AES-256-GCM,
  enc:v1: 前缀,密钥轮换(OldKeys 解码 + 新钥加密)
- harden.go:数据目录权限收紧
- embedded.go:支持内嵌主密钥(可选,仍保留外部 key 文件路径)
- EncryptExistingSecrets / AuditSecrets:启动时幂等迁移 + 审计

## close 纪律(用户明确要求:只要调 close 就要有前置检查)

internal/safeclose:Safe / SafeFunc。全仓 37 处裸 close(chan) → 0。
关键教训(都写进注释和判据):
 · `select { case <-ch: default: close(ch) }` **不是**并发安全的
   (两个 goroutine 可同时命中 default)—— healthcheck 原先是这种写法
 · `sync.Once` **不可重入**:X.Do(func(){ Safe(&X, ...) }) 会自锁,
   症状是 go test 直接挂住(3 个包 600s 超时),栈里只有嵌套的 Once.Do
 · map 里按请求持有的 channel(mcp/stdio.go、clawhubadapter/sidecar.go)
   改成 *pendingRPC 包装,每通道一个 once

## 判据

security 全量 + TestNoBareCloseOutsideSafeclose(AST 级扫描,含注释剥离)
+ TestNoNestedSelfOnceDeadlock(正则修正:\w+ 不匹配点号,捕获组要含 '.')。
变异 2/2 咬住。全量 52 包 ok。

* feat(plugin+deploy): 插件三态生命周期、数据目录迁移、发行包修复

## 插件三态生命周期(用户要求:自动启动 / 启用但不自动启动 / 禁用)

- Manifest 新增 requires_facilities / auto_start(*bool,用于区分
  "未声明"与"显式 false")
- plugin-host 模块(internal/kernelmod/pluginhost):用 kernelboot.Scheduler
  按依赖时机拉起,**不再手写两阶段**
- 运行态停启 StopPlugin/StartPlugin **可逆**:不写 disabled_plugins
  (不改用户决定)、不置 shuttingDown(之后还能加载)、会摘掉注册面
- 与 StopAll 的区别写进注释 —— StopAll 置 shuttingDown 后**永久无法加载**,
  那是进程退出用的,误用于"暂停"就是关了就死

## 数据目录迁移(伪关机 → 迁移 → 唤醒)

- kernelboot/lifecycle.go:Quiesce/Resume(可逆,区别于一次性 CloseAll),
  逆序暂停、逆序恢复、Pause 失败回滚
- kernelboot/migrate.go:BeginMigration/End 编排(先停插件 → 再停内核写者
  → 等在途归零)
- distiller/textmem 增 Pause/Resume 门(不是 cancel —— cancel 不可逆,
  恢复要重建整个对象)
- 模块 migration:体检 + 生成可执行迁移脚本

★ 迁移脚本的三个实测教训(都写成了判据):
 1. 无条件改 /etc/systemd/system ⇒ 演练把**生产** -data 改成了演练目录。
    加 --dry-run(零改动)+ 强制校验 systemd 当前 -data == OLD
 2. 本机没装 rsync,脚本在"服务已停、数据未搬"处硬失败 ⇒ cp -a 回退,
    并明确警告不保硬链接/ACL(生产 plugindev 有大量 git 硬链接)

## 发行包修复(全部经实测确认)

 1. package-linux.sh **完全漏打 depgraph.bin** ⇒ 内核 exit 1
    ("生产构建(内嵌 hash 非空)但读不到依赖图")
 2. build_homed 不走 Makefile ⇒ 单独修 Makefile 无效,必须同时生成图+注入
 3. build.sh 的 LDFLAGS 用**历史模块路径 gitcode.com** ⇒ -X 静默 no-op
    ⇒ --version 显示 unknown
 4. Makefile -ldflags 用**单引号** ⇒ 注入了字面 $GRAPH_HASH

## ★ build.sh 的版本号必须校验(真实事故)

原 `VERSION="$(git describe --tags --dirty)"`。无 tag 分支上它返回**分支名**
`backup/pre-identity-rewrite-20261005-51-g03d87a4e-dirty`,被注入 meta.Version
⇒ 插件握手判据 MajorVersion() 把整串当主版本 ⇒ **22 个子进程插件全部
握手失败**("主版本不匹配")。内核活着、systemd active、日志每条都像
插件的问题 —— 实际是发行包带着非法版本号。

修法:git describe 只在形如 vX.Y.Z 时采用,否则回退 meta.Version(权威源),
并对最终值做形态守卫。deploy/packaging/version_guard_test.go 3 条判据,
变异 2/2 咬住。

## deb 的 systemd unit 改为 guard 模式

ExecStart=/usr/bin/homed --role=guard --data /var/lib/homeagent
(worker exit 42 → guard 重拉,不经过 systemd、不计失败)
含 RestartSteps/RestartMaxDelaySec/TimeoutStopSec + 硬化
(NoNewPrivileges/ProtectSystem/ProtectHome/DevicePolicy/ReadWritePaths)。

## 其他

- internal/plugin/proc:非法 JSON 帧的报错**可定位**(内容摘要 + 可能原因 +
  修法)。生产实测 1038 条非法帧(插件往 stdout 打日志 = 污染协议通道)
- 示例插件 4 个 14 处 fmt.Printf → log.Printf
- hmapdev 模板同步修复;scaffold 判据剥离注释(模板注释里就含 fmt.Printf)

* chore: 收尾(主密钥轮换命令、IPC/知识库加固、SDK 对齐)

- cmd/homed-key-rotate:把 security 里的 RotateKey/RotateKeyFile/RekeySecrets
  串成一条**可执行**的运维路径。没有它,E-1 就只是库里的能力而不是
  "出事时能做的事",而轮换的价值恰恰在于能执行。
- cmd/homed:kmod_runtime(模块装配入口)、plugins_scheduled(failback
  白名单)、memcandidate、bootstrap_order_test / shutdown_flush_test
- internal/ipc、internal/devicebridge、internal/knowledge:配套加固
- third_party/homeagent-sdk/sdk:PluginMgrAPI 增三态能力(mgrStop/mgrStart/
  mgrIsRuntimeStopped)+ settings 对齐

判据:bootstrap_order_test(启动顺序不依赖手写序列)、
shutdown_flush_test(停机的两条路径必须对称 —— exit 42 会跳过 defer,
热更新路径下模块关闭/flush 曾全部丢失)。

* test(security): 测试夹具改用不可误认的占位值(修 push protection 拦截)

GitHub secret scanning 拦住了推送:三处测试夹具用了"看起来像真密钥"的
字面量:

  internal/security/prefilter_test.go:39
  internal/security/store_test.go:177
  internal/security/survey_test.go:20

它们全是**假密钥**(`AKIAIOSFODNN7EXAMPLE` 是 AWS 官方文档的标准示例,
其余是 `abcdefghij...` 这类可读占位符),但扫描器无法区分 —— 它只看形态。

★ 不绕过(不用 unblock URL、不加 allowlist):直接改夹具。
原因:一旦允许"假密钥可以通过",真密钥混进来时就没有最后一道门了。

改法:保留**模式库匹配所需的结构**,把可识别内容换成 FAKE:
  glpat-abcdefghijklmnopqrst       → glpat-FAKE-TEST-TOKEN-NOT-REAL
  sk-abcdefghij...012345           → sk-FAKE-TEST-KEY-NOT-REAL-0000000
  AKIAIOSFODNN7EXAMPLE             → AKIA0000FAKE0000TEST   (保持 20 字符)
  ASIAIOSFODNN7EXAMPLE             → ASIA0000FAKE0000TEST
  xoxb-123456789012-abcdefghijklmnop → xoxb-FAKE-TEST-TOKEN-NOT-REAL

★ 中途踩到一次:AWS 键的模式是 `\b(AKIA|ASIA)[0-9A-Z]{16}\b`(共 20 字符),
我第一次替换成 19 字符的 `AKIAFAKETESTKEY0000` ⇒ 模式匹配不上 ⇒
TestSurvey_WhatIsCaught / TestRecognizesCommonShapes /
TestPrefilterNeverBlocksRealMatches 三条当场变红。
判据正确地拒绝了"为了过扫描器而削弱覆盖"。

顺带核实:全仓 grep 无任何真实密钥泄漏。

* fix(packaging): package-linux.sh 的版本解析与 build.sh 统一

上一版只修了 build.sh,漏了 package-linux.sh —— 它仍只看 git describe:

  VERSION="${VERSION:-$(git describe --tags --dirty)}"

无 tag 分支上 git describe 返回**分支名**
(backup/pre-identity-rewrite-20261005-56-g98850e1),守卫会正确拒绝,
但要求人**手动传 VERSION** 才能打包。而 build.sh 早已能自动回退 meta.Version
⇒ 同一个版本,走 build.sh 打得出来、走 package-linux.sh 打不出来。

危害不只是"要手动传参":运维为了跑通会去掉守卫,而分支名一旦进
meta.Version 就是**插件协议主版本**的来源 ⇒ 22 个子进程插件全部握手失败
(这是真实发生过的事故,见 3efa4e5)。

修法:两个脚本用同一套规则(git describe 仅在 vX.Y.Z 形态时采用,
否则回退 meta.Version),并对最终值做形态守卫。

判据:TestBothPackagingScriptsShareVersionRules —— 逐个读两个脚本,
要求都能从 meta/meta.go 取权威版本、都校验 git describe 形态。
变异(把 package-linux.sh 改回旧规则)咬住并准确指出是哪个脚本。

实测:不传 VERSION 跑 package-linux.sh,输出
  [PKG] warn: git describe 给出非版本串(...),改用 meta.Version=1.4.0
  Version: 1.4.0

* fix(test): 跨仓判据在 CI 上应 skip 而非 fail(修 PR 双红)

CI 上 "Go build / vet / test" 与 "Build linux/amd64" 双红:

  --- FAIL: TestHmapdevTemplateImplementsAllPluginMgrMethods
      bridge_sync_test.go:170: 读模板: open
      ../../../third_party/homeagent-sdk/tools/hmapdev/templates/proc_main.go.tmpl:
      no such file or directory

## 根因:判据依赖了一个**被 gitignore 的路径**

`.gitignore:33` 有 `third_party/homeagent-sdk/tools/`(SDK 仓自治,本仓不跟踪)。
于是:
  · 本机(完整 SDK 检出)有该文件 ⇒ 判据通过
  · CI(只 checkout 本仓)没有该文件 ⇒ Fatalf ⇒ **必红**

我提交时只在本机跑测试、没看 CI,所以这个问题拖到 PR 才暴露。

## 修法

文件缺失时 `t.Skipf` 而不是 `t.Fatalf`。

★ 这不是"放弃检查":
  · 跨仓一致性由 **SDK 仓自己的判据**守着
    (tools/hmapdev/scaffold_stdout_test.go 等),那里才是模板的真实归属地
  · 本判据在本机开发时**仍然生效**(已验证:有文件时 PASS,缺文件时 SKIP)

## 验证

 · 本机(有文件)  → PASS(判据真跑)
 · 模拟 CI(移走 tools/)→ SKIP(不再 fail)
 · 全量 53 包 ok / 0 fail

## 顺带

同目录还有 e2e_template_test.go 也读 tools/,但它是 `//go:build` 门控的
e2e 判据,CI 默认不跑,无需处理。

---------

Co-authored-by: JianFeeeee <JianFeeeee@users.noreply.gitcode.com>
2026-10-17 19:18:24 +08:00

413 lines
14 KiB
Go
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

package kernelboot
// syncbus + 插件调度器的判据(2026-10-16)。
//
// 设计见 docs/zh/kernel-modularization-design.md §2.6。
//
// 这组判据里**最重要的一条是"默认路径为零改动"**:
// 存量 42 个插件都不声明依赖,它们的启动时机必须逐字不变。
// 静默改变启动时机 = 静默引入竞态。
import (
"reflect"
"strings"
"sync"
"testing"
"time"
)
// ★★★ 判据(最关键):**未声明依赖的插件等内核完全初始化**(存量兼容)。
//
// 这是整个设计里风险最高的一处:若未声明的插件被"提前"拉起,
// 42 个存量插件的启动时机全部改变 ⇒ 静默竞态。
//
// 反例(若实现错误):把"未声明"当成"依赖集为空",而空集在数学上已满足
// ⇒ 第一层完成后就拉起 ⇒ 比现状早得多。
func TestSchedulerUndeclaredWaitsForKernelComplete(t *testing.T) {
bus := NewSyncBus()
var launched []string
var mu sync.Mutex
sch := NewScheduler(bus, func(p PluginSpec) error {
mu.Lock()
launched = append(launched, p.Name)
mu.Unlock()
return nil
})
// 存量插件:不声明依赖
sch.Submit([]PluginSpec{{Name: "legacy1", AutoStart: true}})
sch.Submit([]PluginSpec{{Name: "legacy2", AutoStart: true}})
// 内核还在装配中(几层已就绪,但没完成)
bus.MarkLayerReady([]string{"config"})
bus.MarkLayerReady([]string{"memory", "lua"})
bus.MarkLayerReady([]string{"llm"})
mu.Lock()
n := len(launched)
mu.Unlock()
if n != 0 {
t.Fatalf("★ 内核尚未完全初始化,未声明依赖的插件就被拉起了 %d 个(存量行为被改变)", n)
}
// 内核完成 ⇒ 现在才该拉起
bus.MarkKernelComplete()
mu.Lock()
defer mu.Unlock()
if len(launched) != 2 {
t.Fatalf("内核完成后应拉起 2 个,实际 %d: %v", len(launched), launched)
}
}
// ★★★ 判据:**声明了依赖的插件在依赖就绪时立即拉起**(新能力的正面证据)。
//
// 断言"早于内核完成" —— 否则这条判据在"等内核完成"的实现下也会通过(假绿)。
func TestSchedulerDeclaredLaunchesEarly(t *testing.T) {
bus := NewSyncBus()
var launched []string
var mu sync.Mutex
sch := NewScheduler(bus, func(p PluginSpec) error {
mu.Lock()
launched = append(launched, p.Name)
mu.Unlock()
return nil
})
// ★ 镜像真实顺序:Run 在**执行前** MarkDeclared(登记全部模块设施名),
// 插件 Submit 在装配之后发生 ⇒ 判据必须先声明再提交。
bus.MarkDeclared([]string{"config"})
// 声明只需要 config
sch.Submit([]PluginSpec{{Name: "early", RequiresFacilities: []string{"config"}, AutoStart: true}})
// 第 0 层只提供 config ⇒ 应立刻拉起
bus.MarkLayerReady([]string{"config"})
mu.Lock()
got := append([]string{}, launched...)
mu.Unlock()
if len(got) != 1 || got[0] != "early" {
t.Fatalf("★ 依赖已就绪却未拉起: %v", got)
}
// ★ 关键:此时内核**尚未**完成 —— 证明它是"尽早启动"而不是"等完成"
if bus.KernelComplete() {
t.Fatal("测试设置错误:此刻内核不该已完成")
}
}
// ★★★ 判据:**依赖未齐则挂起**,不会误拉起。
func TestSchedulerWaitsForMissingDependency(t *testing.T) {
bus := NewSyncBus()
var launched []string
sch := NewScheduler(bus, func(p PluginSpec) error {
launched = append(launched, p.Name)
return nil
})
// ★ 先声明 llm(登记名字,但尚未就绪)—— 与真实顺序一致。
bus.MarkDeclared([]string{"llm", "config", "memory"})
// 需要 llm
sch.Submit([]PluginSpec{{Name: "needsllm", RequiresFacilities: []string{"llm"}, AutoStart: true}})
bus.MarkLayerReady([]string{"config", "memory"}) // llm 还没好
if len(launched) != 0 {
t.Fatalf("★ llm 未就绪却拉起了: %v", launched)
}
if p := sch.Pending(); len(p) != 1 {
t.Fatalf("应挂起 1 个,实际 %v", p)
}
// llm 就绪 ⇒ 拉起
bus.MarkLayerReady([]string{"llm"})
if len(launched) != 1 || launched[0] != "needsllm" {
t.Fatalf("llm 就绪后应拉起: %v", launched)
}
}
// ★★★ 判据:**只读隔离**(编译期保证,不是约定)。
//
// 断言 Scheduler 拿到的接口**没有**写方法 —— 如果给它 *SyncBus,
// 它就能谎报内核状态,让插件在依赖不存在时启动(病 A)。
func TestSchedulerCannotWriteSyncState(t *testing.T) {
// ★ 检查必须是**接口类型的方法集**,不是某个具体值。
//
// 我第一次写错了:用 `var st SyncState = NewSyncBus()` 再断言 `st.(writer)` ——
// 那检查的是**动态类型**(*SyncBus 当然有 MarkReady),判据当场报假红。
// 要约束的是"拿到 SyncState 的人**能不能**调写方法" ⇒ 必须查接口的方法集。
rt := reflect.TypeOf((*SyncState)(nil)).Elem()
forbidden := []string{"MarkReady", "MarkKernelComplete", "MarkLayerReady"}
for i := 0; i < rt.NumMethod(); i++ {
m := rt.Method(i).Name
for _, bad := range forbidden {
if m == bad {
t.Fatalf("★ SyncState(插件管理器拿到的接口)暴露了写方法 %s —— "+
"它能谎报内核状态,让插件在依赖不存在时启动(病 A)", m)
}
}
}
// 反向确认:读方法必须在(否则接口退化到没用了)
for _, want := range []string{"IsReady", "Snapshot", "AllReady", "KernelComplete"} {
if _, ok := rt.MethodByName(want); !ok {
t.Errorf("SyncState 缺少读方法 %s", want)
}
}
// Scheduler 持有的字段类型也必须是 SyncState(不能是 *SyncBus)
st := reflect.TypeOf(Scheduler{})
f, ok := st.FieldByName("bus")
if !ok {
t.Fatal("Scheduler 应有 bus 字段")
}
if f.Type.String() != "kernelboot.SyncState" {
t.Fatalf("★ Scheduler.bus 的类型是 %s —— 必须是只读的 SyncState", f.Type)
}
}
// ★★★ 判据:**不伴随启动的插件即使依赖齐了也不自动拉起**(§2.6.6)。
func TestSchedulerAutoStartFalseIsNotLaunched(t *testing.T) {
bus := NewSyncBus()
var launched []string
sch := NewScheduler(bus, func(p PluginSpec) error {
launched = append(launched, p.Name)
return nil
})
bus.MarkDeclared([]string{"config"})
sch.Submit([]PluginSpec{
{Name: "manual", RequiresFacilities: []string{"config"}, AutoStart: false},
})
bus.MarkLayerReady([]string{"config"})
bus.MarkKernelComplete()
if len(launched) != 0 {
t.Fatalf("★ auto_start=false 的插件被自动拉起了(应等显式启用): %v", launched)
}
if len(sch.Pending()) != 1 {
t.Fatalf("它应一直挂起等显式启用: %v", sch.Pending())
}
}
// ★★★ 判据:**就绪顺序可复现**(层内并发不得导致就绪顺序抖动)。
//
// 为何重要:syncbus 的就绪顺序决定哪些插件何时被拉起;
// 若顺序随机,同一份声明两次启动会拉出不同结果 ⇒ 不可审计、不可复现。
func TestSyncBusReadyOrderIsDeterministic(t *testing.T) {
// 模拟"层内并发完成":同一层 8 个设施,用 goroutine 乱序 MarkReady
var first []string
for round := 0; round < 5; round++ {
bus := NewSyncBus()
var wg sync.WaitGroup
fac := []string{"f1", "f2", "f3", "f4", "f5", "f6", "f7", "f8"}
for i, f := range fac {
wg.Add(1)
go func(i int, f string) {
defer wg.Done()
// 反过来启动,制造乱序完成
_ = i
bus.MarkReady(f)
}(i, f)
}
wg.Wait()
got := bus.ReadyInOrder()
if round == 0 {
first = got
continue
}
// 注意:MarkReady(单设施)的顺序本就取决于并发,不保证可复现;
// 设计保证的是 **MarkLayerReady**(层边界一次性写入)可复现。
// 所以这里只断言"同样的输入产生同样的集合"。
if len(got) != len(first) {
t.Fatalf("就绪集合大小抖动: %d vs %d", len(got), len(first))
}
}
// ★ 真正的可复现性断言:MarkLayerReady 一次性写入
var order []string
for round := 0; round < 3; round++ {
bus := NewSyncBus()
bus.MarkLayerReady([]string{"a", "b", "c"})
bus.MarkLayerReady([]string{"d", "e"})
got := bus.ReadyInOrder()
joined := strings.Join(got, ",")
if round == 0 {
order = got
continue
}
if joined != strings.Join(order, ",") {
t.Fatalf("★ MarkLayerReady 的就绪顺序不可复现:\n%v\n%v", order, got)
}
}
if strings.Join(order, ",") != "a,b,c,d,e" {
t.Fatalf("就绪顺序应为层内声明序: %v", order)
}
// ★ 幂等性:**重复标记**同一设施不得重复记录顺序。
//
// 为何要单独断言:Run 的层边界回调可能在某些路径重入
//(且调用方也可能手动重复标记)。若不幂等,order 会不断膨胀
// ⇒ 就绪顺序不再反映真实层序 ⇒ 依赖它的调度判断变得不可解释。
//
// 这条是补的:变异"去掉幂等检查"第一次没被咬住 —— 因为原判据
// 只跑了一份声明、没重复标记,测不到幂等性。
bus := NewSyncBus()
bus.MarkLayerReady([]string{"a", "b"})
bus.MarkLayerReady([]string{"a", "b"}) // 重复
bus.MarkLayerReady([]string{"c"})
if got := strings.Join(bus.ReadyInOrder(), ","); got != "a,b,c" {
t.Fatalf("★ 重复标记导致就绪顺序膨胀(不幂等): %v(期望 a,b,c)", got)
}
}
// ★★★ 判据:**内核未完成时绝不发 KernelComplete**(内核没装好就不该放插件)。
//
// 这条守的是:装配中途失败 ⇒ 未声明依赖的插件**不**被拉起。
func TestRunDoesNotMarkCompleteOnFailure(t *testing.T) {
bus := NewSyncBus()
mods := []Module{
&fakeModule{name: "A", provides: []string{"a"}},
&fakeModule{name: "B", provides: []string{"b"}, initErr: errFake},
}
plan, err := Build(mods)
if err != nil {
t.Fatal(err)
}
if _, err := Run(plan, RunOptions{Bus: bus}); err == nil {
t.Fatal("应失败")
}
if bus.KernelComplete() {
t.Fatal("★ 装配失败了却标记内核完成 —— 未声明依赖的插件会被拉起(病 A)")
}
}
// ★★★ 判据:**Run 在层边界自动发布本层设施**(不用模块自己标记)。
//
// 为何由 Run 做:模块自己标记会漏(静默漏一个设施 ⇒ 插件永远等不到),
// 且顺序取决于层内并发完成序。
func TestRunPublishesFacilitiesAtLayerBoundary(t *testing.T) {
bus := NewSyncBus()
mods := []Module{
&fakeModule{name: "config", provides: []string{"config", "config-write"}},
&fakeModule{name: "llm", provides: []string{"llm"}, requires: []string{"config"}},
}
plan, err := Build(mods)
if err != nil {
t.Fatal(err)
}
if _, err := Run(plan, RunOptions{Bus: bus}); err != nil {
t.Fatal(err)
}
for _, f := range []string{"config", "config-write", "llm"} {
if !bus.IsReady(f) {
t.Errorf("★ 设施 %q 未在层边界被发布", f)
}
}
if !bus.KernelComplete() {
t.Error("全部完成后应标记内核完成")
}
}
// ★★★ 判据:**空依赖列表 ≠ 已满足**(语义区分的直接断言)。
//
// 若这条反了,未声明依赖的插件会被提前拉起(见第一条判据)。
func TestAllReadyEmptyIsFalse(t *testing.T) {
bus := NewSyncBus()
bus.MarkKernelComplete()
if bus.AllReady(nil) {
t.Fatal("★ AllReady(空) 返回 true —— \"没有依赖\"被当成\"依赖全就绪\",未声明插件会提前拉起")
}
if bus.AllReady([]string{}) {
t.Fatal("★ AllReady(空切片) 返回 true")
}
// 非空且齐 ⇒ true
bus.MarkReady("x")
if !bus.AllReady([]string{"x"}) {
t.Fatal("依赖确实就绪应返回 true")
}
}
// ★★★ 判据:**拉起失败不阻塞其他插件**(一个坏插件不该拖垮全局)。
func TestSchedulerLaunchFailureDoesNotBlockOthers(t *testing.T) {
bus := NewSyncBus()
var okLaunched []string
sch := NewScheduler(bus, func(p PluginSpec) error {
if p.Name == "bad" {
return errFake
}
okLaunched = append(okLaunched, p.Name)
return nil
})
var failures int
sch.SetLaunchErrorHandler(func(PluginSpec, error) { failures++ })
bus.MarkDeclared([]string{"config"})
sch.Submit([]PluginSpec{
{Name: "bad", RequiresFacilities: []string{"config"}, AutoStart: true},
{Name: "good", RequiresFacilities: []string{"config"}, AutoStart: true},
})
bus.MarkLayerReady([]string{"config"})
if len(okLaunched) != 1 || okLaunched[0] != "good" {
t.Fatalf("★ 一个插件拉起失败影响了其他插件: %v", okLaunched)
}
if failures != 1 {
t.Fatalf("失败应被报告: %d", failures)
}
}
// ★★★ 判据:**重复 Submit 不重复拉起**(幂等)。
func TestSchedulerIsIdempotent(t *testing.T) {
bus := NewSyncBus()
n := 0
sch := NewScheduler(bus, func(PluginSpec) error { n++; return nil })
bus.MarkKernelComplete()
sch.Submit([]PluginSpec{{Name: "p", AutoStart: true}})
sch.Submit([]PluginSpec{{Name: "p", AutoStart: true}})
bus.MarkKernelComplete() // 再触发一次评估
if n != 1 {
t.Fatalf("★ 同一插件被拉起 %d 次(应幂等)", n)
}
}
// ★★★ 判据:**MarkReady 的通知也在锁外**(走单设施路径的订阅者不死锁)。
//
// 变异 8b 暴露的边界:MarkLayerReady 持锁回调会死锁(已被
// TestSchedulerDeclaredLaunchesEarly 咬住),但 MarkReady 是**另一条路径**
// (单个设施的标记),若它持锁回调,只有"既调 MarkReady 又订阅"的场景才会卡住。
// 补这条判据把两条路径都盖住。
func TestSyncBusMarkReadyNotifiesWithoutDeadlock(t *testing.T) {
bus := NewSyncBus()
got := make(chan string, 4)
// 订阅者**读状态**(真实回调必然会读,这正是死锁触发条件)
bus.OnUpdate(func(s SyncState) {
_ = s.Snapshot() // 持锁调用的话,这里会等 RLock ⇒ 死锁
got <- "ok"
})
done := make(chan struct{})
go func() {
defer close(done)
bus.MarkReady("config")
}()
select {
case <-got:
case <-done:
t.Fatal("★ MarkReady 未通知订阅者(订阅者拿不到更新 ⇒ 插件不会自动拉起)")
case <-timeAfter(5):
t.Fatal("★ MarkReady 持锁调用回调 ⇒ 死锁(回调读状态时会等锁)")
}
}
func timeAfter(sec int) <-chan struct{} {
ch := make(chan struct{})
go func() {
time.Sleep(time.Duration(sec) * time.Second)
close(ch)
}()
return ch
}