[metadata-protocol] seed-loader:无 pass-2 时「引用解析不了 ⇒ 整条记录丢弃」计为 error 却一行日志都不打(#4729 判据的更深一格)

[xuyushun441-sys]

发现于 #4729(把 seed-loader 里「计数为错、日志为 warn」的行对齐到 error)的同文件盘点。本条不在 #4729 的判据内(它盘的是 this.logger.warn 调用),所以只记录、不在那个 PR 里改。

现象

packages/metadata-protocol/src/seed-loader.ts,pass-1 引用解析、multiPass 关闭的分支:

} else {
  // Cannot resolve and no pass 2 will run — skip the whole record
  // (LOUD: counted + reported). Writing it anyway would either
  // carry the raw natural-key string into the FK column or, on
  // update, corrupt the existing row.
  pushError(
    `Cannot resolve reference: ${objectName}.${ref.field} = '${String(unresolvedItem)}' → ` +
      `${ref.targetObject}.${ref.targetField} not found`,
    unresolvedItem,
  );
  unresolvedRefError = true;
}

pushError 把错误推进 errors / allErrors(⇒ success: false),随后 unresolvedRefError 让 errored++ 并 continue —— 整条记录被丢弃,一行都没有种下去。但这里没有任何 logger 调用:注释写的 "LOUD" 只兑现了「计入结果对象」,控制台上一个字都没有。

为什么值得单开

#4729 的论点是「计数与日志级别应当一致」:结果对象里数得到、日志却停在没人读的 warn。这一处是同一条链的更深一格 —— 计数有、日志级别是「无」。对只看 boot 日志的运维/agent 来说,一次丢了 N 条记录的 seed 与一次干净的 seed 在控制台上完全一样(区别只在调用方是否检查了 result.success,而 packages/runtime 的若干 seed 调用点只是 await 之后继续)。

check:durability-log-level 把这种形态叫 silent-swallow,但那个门禁只扫 try/catch,而这里不是 catch,所以扫不到。

期望(待维护者确认)

• 在该分支补一条 this.logger.error(...),按 [convention] best-effort 降级导致"看起来正常、实则不持久"时不应记 warn——把 #4460 的点状修复定成规则 #4632 的要求说清后果(<object> 第 #i 条记录整条未种下,因为 <object>.<field> 指向的 <target> 不存在)与修复动作(先种目标对象、或打开 multiPass 让 pass 2 回填、或修掉 seed 里的自然键);
• 顺带确认 dry-run 分支([dry-run] Reference may not resolve)是否也该有一行 —— 那一处同样只进结果对象、不进日志,但 dry-run 的调用方本来就是来读结果的,可能维持现状更合适。

未认领。