[metadata-protocol] seed-loader:roll-up summary 重算耗尽重试后只记 warn 且不计数 —— 落盘的汇总值与事实不符,seed 仍报 success: true

[xuyushun441-sys]

发现于 #4729(seed-loader 的日志级别盘点)。本条不在 #4729 的判据(「计数为错、日志为 warn」)内 —— 它压根不计数 —— 所以只记录,不在那个 PR 里动。

现象

packages/metadata-protocol/src/seed-loader.ts 的 writeRecoveringSummary():

private async writeRecoveringSummary(fn: () => Promise<T>): Promise<T> {
  try {
    return await fn();
  } catch (e: any) {
    if (e?.code === 'ERR_SUMMARY_RECOMPUTE') {
      this.logger.warn(
        '[SeedLoader] roll-up summary recompute failed after retries; records were written (summary values may be stale)',
        { failures: Array.isArray(e.failures) ? e.failures.length : undefined },
      );
      return e.written as T;
    }
    throw e;
  }
}

行本身的判断是对的(framework#3147:记录确实写进去了,不能重写,否则重复)。有疑问的是后果的等级:roll-up summary 是一列已持久化的派生值,重算耗尽重试后,库里存着的汇总数与被汇总的明细不一致,而:

• 这次 seed 不计一条错(errored 不动、allErrors 不动),result.success 仍是 true;
• 控制台上唯一的痕迹是一行 warn。

判定问句(#4632 / AGENTS.md「Degradation log levels」)

降级之后系统对外是否仍然「正常」,而某个声称已持久化的东西实际不对?

我的读法是 是:一切看起来干净(success: true,行数全对),而一列已落盘的汇总值是错的,并且不会自己修 —— 直到下一次触发该 summary 重算的写入才可能纠正,而 seed 之后未必还有这种写入。这正是 #4420 的形态(那次是 in-flight approvals,这次是汇总列)。

反方也有分量,所以我不想擅自改:

1. 记录本身是真的落盘了,和 [automation/approvals] 进程重启后审批决策静默失效:挂起 flow run 仍只存内存(#1518 标记 COMPLETED 但 17.0.0-rc.1 未生效),approve 落库却永不推进且零报错 #4420「写入完全没发生」不同;
2. 提到 error 会让一次除汇总外全部成功的 seed 打出 error 行,可能属于 AGENTS.md 明确警告的「过度适用」(把人训练成跳过 error);
3. 也可以不动日志级别,而是把它计入结果(新增一个 summariesStale 计数或一条 ReferenceResolutionError),让结果对象诚实,日志维持 warn。

期望(需要维护者拍板)

在下面三条里选一条并落地 + 加测试:

• A 提到 error,文案说清后果(<object> 的 roll-up summary 列现在是陈旧值,明细与汇总不一致,而 seed 报告 success)与修复动作(修掉下面的重算错误后重跑 seed / 触发一次该对象的写入以重算);
• B 保持 warn,但计入结果对象(新增计数字段),让调用方能发现;
• C 判定其为「功能性降级」,维持现状,并在注释里写明为何不属于 [convention] best-effort 降级导致"看起来正常、实则不持久"时不应记 warn——把 #4460 的点状修复定成规则 #4632 的第二类,免得下一个人再翻一遍。

我的倾向是 A + B:后果确实是「已落盘的数据不对」,而且计数与日志级别应当一致(#4729 的同一条论点)。但这会改变一次成功 seed 的控制台输出,属于产品口径,不该由实现方顺手决定。

未认领。