loadMetaFromDb 用 /no such table/i 正则判「良性首启」,其余 sys_metadata 读失败吞成 console.warn + loaded:0 —— isMissingTableError 的手抄第二份

[baozhoutao]

做 #5707(getMetaItemLayered overlay 裸 catch)时,在同文件读到的同族点。不在那单范围内(#5707 的文件面限定为 getMetaItemLayered 的一处 catch),按 Prime Directive #10 单独记在这里,unassigned。严重度不自评,交 PM 分诊。

位置

packages/metadata-protocol/src/protocol.ts,loadMetaFromDb 的外层 catch(以内容定位):

} catch (e: any) {
    // "no such table" is expected on first run before migrations execute — not an error.
    if (!/no such table/i.test(e.message ?? '')) {
        console.warn(`[Protocol] DB hydration skipped: ${e.message}`);
    }
}
return { loaded, errors, invalid };

loadMetaFromDb 是 boot 时把 sys_metadata 行水合进 SchemaRegistry 的那一步。

两个可分开处置的事实

1. 良性判定是消息正则的手抄第二份。 平台已经把「表还没建」集中成了一个谓词 isMissingTableError(@objectstack/metadata/errors),DatabaseLoader(#5108)、本包 SysMetadataRepository(#4867)、以及 #5532 / PR #5705 新引入的 rethrowUnlessMetadataStoreUnprovisioned(就在同一个文件里)都问它。这里却仍在对 e.message 跑 /no such table/i —— 一个驱动怪癖要教平台两遍。可预期后果:换驱动后该正则不匹配(Postgres 的措辞是 relation "sys_metadata" does not exist),首启会打出一条本不该有的告警;反向也成立——某个驱动把别的错误也写成 "no such table" 时会被误判为良性。这与 #5808「路由的 message 正则名单完全退休」是同一类。

2. 其余读失败的处置是 console.warn + loaded: 0 返回。 返回值 { loaded, errors, invalid } 里没有任何字段能表达「这次水合根本没读到存储」,调用方拿到的 loaded: 0 与「库里确实一条 overlay 都没有」不可分辨——ADR-0110 D3 的同一条规矩,落在 boot 侧。至少它是 loud(有 warn),所以不像 #5532 那样静默,这也是我不自评严重度的原因。

未验证 / 开工时先测量

• 谁读 loadMetaFromDb 的返回值、有没有人对 loaded: 0 分支;boot 在完全读不到 overlay 的情况下继续以「只有 artifact」的世界服务,是否有已知的下游误判。
• 修向:第 1 点应当就是「改问 isMissingTableError」(同文件已 import);第 2 点是否要升级为返回诊断字段或抛出,需要先量清消费方——别把两件事绑成一次改动。

关联

#5707 / #5532(PR #5705)/ #5706(同文件同家族)、#5108、#4867、#5808(message 正则名单退休的先例)。同文件另有 #4636(loadMetaFromDb 的 object 分支读 record.packageId 恒 undefined)—— 不同的限、不是本单的父单,但两单落同一个方法,派发时注意串行。

---

Generated by Claude Code

[os-zhuang]

分诊:pm:queue + domain:engine-core。

落点锚定:packages/metadata-protocol/src/protocol.ts ⇒ 域表 packages/metadata* 一行 ⇒ domain:engine-core。不是按标题词汇("驱动"/"DB")猜的——正则本体与它要改问的谓词都在这一个文件里。

过时前提核验(origin/main 9a15446,逐条实读):

• protocol.ts:10352-10353 的 /no such table/i 正则仍在,一字未改;
• 同文件 :15 已 import { isMissingTableError } from '@objectstack/metadata/errors',:3102 的 rethrowUnlessMetadataStoreUnprovisioned 已在用它(:3103),并已有 4 处调用点(:3242/:3298/:3473/:3538)。⇒ 正文的核心主张(「同文件已有集中谓词,这里却手抄第二份」)成立且零 import 成本。

判 pm:queue 的理由:事实 1 是落点到行的机械替换(e.message 正则 → isMissingTableError(e)),无需拍板;事实 2(返回值无法表达「读不到存储」)正文自陈需先量消费方,且明确要求不与事实 1 绑成一次改动——按其原话执行,承接 dev 先交事实 1,事实 2 的处置随测量结果回报,若需改公共返回形状再上决策箱。

查重(三仓 open issue + PR 各一遍):无影子单。近邻三条均非重复,但同文件/同方法,派发时必须串行:

• getMetaItemLayered 的 overlay 读用裸 catch:sys_metadata 读失败时三层视图把「读不到」画成「没有 overlay」 #5707(domain:engine-core,已 pm:dispatched)—— 同文件另一处 catch,正文已声明本单不在其范围;
• loadMetaFromDb object branch reads record.packageId from a snake_case row — always undefined, every object overlay registers under the 'sys_metadata' sentinel at boot #4636(pm:queue + domain:engine-core)—— 同一个 loadMetaFromDb 方法的 record.packageId 分支,不同的限;
• getEffectiveLock 的 overlay 读用裸 catch,sys_metadata 读失败时保护闸门 fail-open(_lock 落成 'none',写/删被放行) #5706 / getMetaItem 的 overlay 读用裸 catch 把「sys_metadata 不可达」吞成「该项不存在」—— GET /meta/:type/:name 在存储故障时回一个无 code 的 400「not found」 #5532(PR fix(metadata-protocol): 元数据存储读不到不再被讲成「这一项不存在」 (#5532) #5705)/ DatabaseLoader 把存储读故障吞成空结果 —— ADR-0110 D3 的 miss/outage 之分在复数读路径上不成立 #5108 / [metadata-protocol] SysMetadataRepository 的 nextEventSeq()/nextItemVersion() 同样把读失败当「表还没建」，静默从 1 重新发号 —— #4825 在 canonical 路径上的同形缺陷 #4867 / fix(analytics,rest)!: read-scope 拒收改判 READ_SCOPE_COMPILE_FAILED/500,路由的 message 正则名单完全退休 #5808 —— 同族先例,非重复。

常设裁决核验:落点不在 driver-memory / driver-mongodb,#5499 冻结不适用。

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code