feat: load genesis config from domain

[askyrie]

This PR is for:

• Server

[claude]

Claude finished @askyrie's task in 2m 36s —— View job

---

a. 事件类型：PR 上的 issue comment 追问，用户说“修复了，再检查下”，需要基于当前分支最新代码做一次复核。 b. 这是代码 review / 复核请求，不是实现请求。 c. 关键信息：仓库 `deepflowio/deepflow`，PR #11627，分支 `genesis_config_from_cloud -> origin/main`；本次重点复核上轮指出的 `ignore_nic_regex` 空字符串问题，以及相关配置加载逻辑是否还有边界问题。 d. 主要任务：更新检查清单、阅读最新 PR diff 与相关文件、重新判断是否还存在正确性/可维护性问题、用中文给出复核结论。 e. 计划：阅读 `origin/main...HEAD` 的最新 diff，并核对 `@server/controller/genesis/updater/sync.go`、`@server/controller/genesis/store/sync/mysql/run.go`、`@server/controller/genesis/common/utils.go` 的当前实现；本次不做代码修改。 f. 说明：以下结论基于静态代码分析，未做运行时验证。

任务进度

• 更新 GitHub 评论中的检查清单
• 阅读最新 PR diff 和相关文件
• 复核修复后的代码是否还存在问题
• 用中文更新 review 结论

复核结果

我重新看了这版，上轮提的 ignore_nic_regex: "" 会误伤所有网卡的问题已经修掉了。

现在 @server/controller/genesis/updater/sync.go:159-164 已经改成只有在 domain config 里的 ignore_nic_regex 是非空字符串时才会编译覆盖，因此空字符串不会再变成一个“匹配所有字符串”的正则；而基线配置仍然在 @server/controller/genesis/updater/sync.go:68-80 先从 yaml 加载，这部分逻辑是对的。

不过我这次继续看下来，还有 1 个剩余边界问题：

1. 非法的 domain ignore_nic_regex 会把 yaml 默认正则清空，而不是回退到基线值
   当前流程是：

   • 先在 @server/controller/genesis/updater/sync.go:77 编译 yaml 的 config.IgnoreNICRegex
   • 再在 @server/controller/genesis/updater/sync.go:159-163 编译 domain 下发的 ignore_nic_regex

   这里如果 domain 侧下发的是非法正则，比如 "("，regexp.Compile() 会返回 nil, err，而这句赋值：

   v.ignoreNICRegex, err = regexp.Compile(ignoreNICRegex)

   会直接把之前已经生效的 yaml 默认值覆盖成 nil。

   后面 @server/controller/genesis/updater/sync.go:211-212：

   if v.ignoreNICRegex != nil && v.ignoreNICRegex.MatchString(item.Name) {
       continue
   }

   由于 v.ignoreNICRegex 已经变成 nil，结果就是默认过滤规则也失效了。以当前默认配置 @server/controller/genesis/config/config.go:32 的 ^(kube-ipvs) 为例，坏的 domain 配置会让原本应被忽略的网卡重新进入同步结果。

   如果预期是“domain 覆盖无效时保留 yaml 基线”，那这里还需要再补一下：先编译到临时变量，成功后再覆盖 v.ignoreNICRegex。

   Fix this →

其他观察

• @server/controller/genesis/store/sync/mysql/run.go:421-430 现在仍然是按 org 复用 updater，并按 org 做分钟级刷新，这部分和 LoadConfig() 的状态模型是一致的。
• @server/controller/genesis/common/utils.go:564-623 抽出来的 IPsToPrefixes() / CoolDownFunc 这次没有看到新的明显问题。
• @server/controller/genesis/updater/sync.go:166 只打印 domain 名，不再直接打整段 domain.Config，这点保持得也没问题。

结论

• 上轮指出的空字符串问题，这版已经修复。
• 目前我还能确认的剩余问题，是非法的 domain ignore_nic_regex 会把 yaml 基线过滤规则清空。 如果你们能保证 domain 配置一定是合法正则，那可以接受；否则我建议合并前把这个回退语义补完整。

[askyrie]

Claude finished @askyrie's task in 2m 36s —— View job

a. 事件类型：PR 上的 issue comment 追问，用户说“修复了，再检查下”，需要基于当前分支最新代码做一次复核。 b. 这是代码 review / 复核请求，不是实现请求。 c. 关键信息：仓库 deepflowio/deepflow，PR #11627，分支 genesis_config_from_cloud -> origin/main；本次重点复核上轮指出的 ignore_nic_regex 空字符串问题，以及相关配置加载逻辑是否还有边界问题。 d. 主要任务：更新检查清单、阅读最新 PR diff 与相关文件、重新判断是否还存在正确性/可维护性问题、用中文给出复核结论。 e. 计划：阅读 origin/main...HEAD 的最新 diff，并核对 @server/controller/genesis/updater/sync.go、@server/controller/genesis/store/sync/mysql/run.go、@server/controller/genesis/common/utils.go 的当前实现；本次不做代码修改。 f. 说明：以下结论基于静态代码分析，未做运行时验证。

任务进度

• 更新 GitHub 评论中的检查清单
• 阅读最新 PR diff 和相关文件
• 复核修复后的代码是否还存在问题
• 用中文更新 review 结论

复核结果

我重新看了这版，上轮提的 ignore_nic_regex: "" 会误伤所有网卡的问题已经修掉了。

现在 @server/controller/genesis/updater/sync.go:159-164 已经改成只有在 domain config 里的 ignore_nic_regex 是非空字符串时才会编译覆盖，因此空字符串不会再变成一个“匹配所有字符串”的正则；而基线配置仍然在 @server/controller/genesis/updater/sync.go:68-80 先从 yaml 加载，这部分逻辑是对的。

不过我这次继续看下来，还有 1 个剩余边界问题：

1. 非法的 domain ignore_nic_regex 会把 yaml 默认正则清空，而不是回退到基线值
   当前流程是：

   • 先在 @server/controller/genesis/updater/sync.go:77 编译 yaml 的 config.IgnoreNICRegex
   • 再在 @server/controller/genesis/updater/sync.go:159-163 编译 domain 下发的 ignore_nic_regex

   这里如果 domain 侧下发的是非法正则，比如 "("，regexp.Compile() 会返回 nil, err，而这句赋值：

   v.ignoreNICRegex, err = regexp.Compile(ignoreNICRegex)

   会直接把之前已经生效的 yaml 默认值覆盖成 nil。
   后面 @server/controller/genesis/updater/sync.go:211-212：

   if v.ignoreNICRegex != nil && v.ignoreNICRegex.MatchString(item.Name) {
       continue
   }

   由于 v.ignoreNICRegex 已经变成 nil，结果就是默认过滤规则也失效了。以当前默认配置 @server/controller/genesis/config/config.go:32 的 ^(kube-ipvs) 为例，坏的 domain 配置会让原本应被忽略的网卡重新进入同步结果。
   如果预期是“domain 覆盖无效时保留 yaml 基线”，那这里还需要再补一下：先编译到临时变量，成功后再覆盖 v.ignoreNICRegex。
   Fix this →

其他观察

• @server/controller/genesis/store/sync/mysql/run.go:421-430 现在仍然是按 org 复用 updater，并按 org 做分钟级刷新，这部分和 LoadConfig() 的状态模型是一致的。
• @server/controller/genesis/common/utils.go:564-623 抽出来的 IPsToPrefixes() / CoolDownFunc 这次没有看到新的明显问题。
• @server/controller/genesis/updater/sync.go:166 只打印 domain 名，不再直接打整段 domain.Config，这点保持得也没问题。

结论

• 上轮指出的空字符串问题，这版已经修复。
• 目前我还能确认的剩余问题，是非法的 domain ignore_nic_regex 会把 yaml 基线过滤规则清空。 如果你们能保证 domain 配置一定是合法正则，那可以接受；否则我建议合并前把这个回退语义补完整。

@claude 修复了，再检查一下

[claude]

Claude finished @askyrie's task in 2m 1s —— View job

---

a. 事件类型：PR 上的 issue comment 追问，用户说“修复了，再检查一下”，需要基于当前分支最新代码做一次复核。 b. 这是代码 review / 复核请求，不是实现请求。 c. 关键信息：仓库 `deepflowio/deepflow`，PR #11627，分支 `genesis_config_from_cloud -> origin/main`；本次重点复核上轮指出的非法 `ignore_nic_regex` 回退问题是否已修复，并继续检查相关配置加载边界。 d. 主要任务：更新检查清单、阅读最新 PR diff 与相关文件、复核修复结果、用中文更新 review 结论。 e. 计划：查看 `origin/main...HEAD` 的最新 diff，并核对 `@server/controller/genesis/updater/sync.go`、`@server/controller/genesis/store/sync/mysql/run.go`、`@server/controller/genesis/common/utils.go` 等相关实现；本次不做代码修改。 f. 说明：以下结论基于静态代码分析，未做运行时验证。

任务进度

• 更新 GitHub 评论中的检查清单
• 阅读最新 PR diff 和相关文件
• 复核修复后的代码是否还存在问题
• 用中文更新 review 结论

复核结果

我重新看了最新这版，上轮提的非法 domain ignore_nic_regex 会清空 yaml 基线过滤规则的问题已经修好了。

现在 @server/controller/genesis/updater/sync.go:160-166 改成了：先把 domain 下发的 ignore_nic_regex 编译到临时变量，只有编译成功才覆盖 v.ignoreNICRegex；失败时只记日志，继续保留前面在 @server/controller/genesis/updater/sync.go:76-81 从 yaml 配置加载出来的基线值。这就避免了像 "(" 这种非法正则把默认过滤规则置空的问题。

本次额外检查

我顺手又扫了一遍这次相关改动，目前没有再看到新的明确正确性问题：

• @server/controller/genesis/updater/sync.go:76-81：yaml 配置非法时会回退到 @server/controller/genesis/common/const.go:34 的默认正则，行为一致。
• @server/controller/genesis/updater/sync.go:160-166：domain 配置为空字符串时不覆盖；非法时保留 yaml 基线；合法时才生效，覆盖语义完整。
• @server/controller/genesis/store/sync/mysql/run.go:408-430：按 org 维度做 updater 复用和冷却刷新，和 LoadConfig() 的状态持有方式是匹配的。
• @server/controller/genesis/common/utils.go:564-623：抽出的 IPsToPrefixes() 和 CoolDownFunc 这次没有看到新引入的明显问题。

结论

这次我复核下来，上轮指出的两个 ignore_nic_regex 边界问题都已经修复，当前版本我这边没有新的阻塞性问题。

补充说明：以上结论基于静态代码阅读，未做运行时验证或回归测试。