Repository navigation
[metadata-protocol] seed-loader:roll-up summary 重算耗尽重试后只记 warn 且不计数 —— 落盘的汇总值与事实不符,seed 仍报 success: true #4998
Description
发现于 #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,这次是汇总列)。
反方也有分量,所以我不想擅自改:
- 记录本身是真的落盘了,和 [automation/approvals] 进程重启后审批决策静默失效:挂起 flow run 仍只存内存(#1518 标记 COMPLETED 但 17.0.0-rc.1 未生效),approve 落库却永不推进且零报错 #4420「写入完全没发生」不同;
- 提到
error会让一次除汇总外全部成功的 seed 打出 error 行,可能属于 AGENTS.md 明确警告的「过度适用」(把人训练成跳过 error); - 也可以不动日志级别,而是把它计入结果(新增一个
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 的控制台输出,属于产品口径,不该由实现方顺手决定。
未认领。
Activity
claude commentedon Aug 4, 2026
维护者已裁:A + B(2026-08-04,经主 backlog PM 呈报后照准)
error,文案带后果(该对象 roll-up summary 列为陈旧值、明细与汇总不一致而 seed 报 success)与修复动作;summariesStale计数),调用方可编程发现;success语义是否翻转按 B 的实现证据定 —— 汇总列错数据不算「成功得干净」。摘
needs-user-decision,回队,本轮即派。Generated by Claude Code
claude commentedon Aug 4, 2026
🔒 认领:PM 循环第 7 轮(维护者裁决落地批)
会话:
session_01NrmBxj8rK2uGCnh9aipjwX(账号xuyushun441-sys)分支:
claude/issue-4998-seed-summary-stale-loudWorktree:
objectstack-issue-4998域:
domain:engine文件面:
packages/metadata-protocol/src/seed-loader.ts(writeRecoveringSummary)及同目录测试⛔ 硬约束:
spec/**及生成物零改动;protocol.ts零改动;releases/ 零触碰。全局在飞不相交已核:与 #5025(sys-metadata-repository.ts + 基线)、#4762(packages/lint)、本批其余两单文件面均不交。
Generated by Claude Code
claude commentedon Aug 4, 2026
PM 中间处置:子问题即裁,B 半边的 spec 例外呈维护者
success不翻转 —— 确认,按 dev 证据即裁(维护者原裁决明言此项交实现证据):三个消费方证据决定性 —— wire 返回结构上无法解释 false 的原因、boot banner 会打出「true and useless」行、marketplace install 会把「行全部落库」的一次安装判失败,直接违反 framework#3147 的「records WERE written」不变量。success语义 = 行是否落库;新计数字段承载陈旧信号。seed-loader.zod.ts),非包内。dev 的方案 A(为本单开一个窄例外:summariesStale+totalSummariesStale,逐字镜像 seed-loader: a dropped reference FIELD is invisible in the summary —totalErroredcounts dropped records only, so the boot banner reads clean #3932referencesDropped先例,纯增量 + default(0),~10 行手写 + 两个生成物重生)已呈维护者拍板;方案 C(包内私加字段、契约分叉)按 PD#12 弃。fn()才能真保护的关键发现)已在停工报告里,解锁即续。Generated by Claude Code
claude commentedon Aug 4, 2026
维护者已裁(2026-08-04):批准本单的 spec 窄例外,取 dev 方案 A
summariesStale(SeedLoadResultSchema)+totalSummariesStale(summary),逐字镜像 seed-loader: a dropped reference FIELD is invisible in the summary —totalErroredcounts dropped records only, so the boot banner reads clean #3932referencesDropped先例,纯增量 +default(0),连同两个生成物重生 —— 本车道单次例外,随本 PR 关闭;success不翻转(已按实现证据即裁);原 dev agent 带上下文续做。⚠️ 入队前按纪律 A 处理 spec 生成物(在飞 #5042/#5043/#5012 同在动 spec)。
Generated by Claude Code
claude commentedon Aug 4, 2026
✅ 验收通过 —— PR #5062(draft,落地按同文件串行排程,见下)
对照实际 diff 复核(9 文件,+676/-34;spec 改动恰在授权例外内:seed-loader.zod.ts + authorable-surface.json + 生成 docs 页各一;⛔ protocol.ts / releases 零触碰,逐一核实):
summariesStale/totalSummariesStale逐字镜像 seed-loader: a dropped reference FIELD is invisible in the summary —totalErroredcounts dropped records only, so the boot banner reads clean #3932 先例,buildResult恒填充,success不翻转(已确认子裁定);框架bug(objectql): 汇总重算失败仅 warn——子记录批量插入报成功,父 summary 静默过期且无重试 #3147 的「行已写入不重写」原样。git diff origin/main --stat恰为本分支两行增量,且 收紧 theme 全部/chart 五个站点的未知键，并按门测量把 chart 两个站点判为 no gate（#4001 批 15） #5043 的兄弟条目(ui/Chart 44、ui/Theme 12)验证存活。落地排程(同文件串行):队列中的 #5025 与本 PR 都改
check-durability-degradation-log-level.mjs—— 本 PR 等 #5025 落地后并 origin/main(冲突就地解决:保留收紧后的门禁逻辑 + #5025 的 dropPromotedDraftRow 登记两者)、重跑该门禁与自测,绿后入队。Generated by Claude Code
Merge remote-tracking branch 'origin/main' into claude/issue-4998-see…
fix(metadata-protocol): seed-loader 中「计为错误」的失败一律记 error,不再自相矛盾地记 warn (…
fix(seed-loader): a roll-up summary left stale by a seed is loud and …