finding(objectql): engine.ts 的 sys_file hydrate 读故障走 `catch → return records` —— 静默返回裸 id,零日志(#5979 实施期扫出,闸门词表外)

[baozhoutao]

发现于 #5979(PR #6114)实施期的邻域清扫,按 Prime Directive #10 只记录不修,未认领。严重度不自评,交分诊。

事实

packages/objectql/src/engine.ts:4686 一带(以内容定位:sys_file 引用 hydrate 的读路径):

} catch {
  return records;
}

sys_file 读不到时原样返回入参(未 hydrate 的裸 id),不记一行日志。

为什么闸门看不见、以及定性

• check-durability-degradation-log-level.mjs 的 read-seam invention 规则(check:durability-log-level 结构性看不见「读接缝把故障答成空值」这一类 —— #4825 / #5108 全家都在闸门盲区里 #5186)扫的是「编造空答案」—— 这里不编造空值(返回的是入参本身),落在词表外;
• 降级对调用方部分可见(拿到裸 id 而非 hydrate 后的文件引用),属功能性降级而非持久性降级,与 fix(metadata,metadata-protocol,objectql): getDiagnosed —— get() 不再把 loader outage 答成「这一项没声明」 (#5840) #6051 里 restoreArtifactRegistryView 的「已声明 best-effort」不同 —— 这里没有任何声明,也没有任何声音;
• 危险方向:消费方(UI/导出)把裸 id 当作「无附件」渲染,故障期间的表现与「记录本无文件」不可分辨 —— ADR-0110 D3 的族形,只是载体是功能面。

同次清扫的相邻点已裁定不立案,一并记录免得下一轮重复裁:engine.ts:3870 的 catch → return { verified: false, conclusive: false } 是显式三态(conclusive 即「读没读成」位),与 baseline 里 referenceExists 的 reviewed-legitimate 同形,站得住。

处置方向(供分诊定价,不预判)

最小:catch 里按 isMissingTableError 判别 + 非良性时 warn(带后果与修法,AGENTS「Degradation log levels」的判定问句:无持久性声称 ⇒ 不升 error);或跟 #5840 的 getDiagnosed 形状对齐把判定交给调用方。是否值得动,交分诊按 finding 池纪律裁。

Refs:#5979 / PR #6114(dev 报告 family_residue 节)、#5186(闸门)、ADR-0110 D3、AGENTS「Degradation log levels」。

[claude]

Findings triage — verdict: PROMOTE to pm:queue (+ domain:engine-core; packages/objectql per the domain table).

Grading rationale — this is not observation-class, and the body's own analysis is why. The filer declined to self-assess severity (correct per os-dev discipline; grading belongs to this round). Read against the three questions this round asks:

1. Does a user hit it today? Yes, during any sys_file read fault: consumers receive bare ids and, as the body says, render them indistinguishably from "this record has no attachment". A fault that presents as legitimate absent data is the ADR-0110 D3 family — the repo's standing "silently wrong answer" shape — and the fact that the carrier is a functional surface rather than a durability one changes the log level, not the classification.
2. Is there a named location and a statable acceptance? Yes: packages/objectql/src/engine.ts around :4686, located by content (the sys_file reference hydrate read path) rather than by line, and the acceptance is one sentence — a non-benign hydrate read failure must be distinguishable from "no file", instead of catch { return records } with zero output.
3. Is a decision pending? No. The body offers a minimum (discriminate with isMissingTableError, warn on the non-benign branch — AGENTS "Degradation log levels" puts it at warn, not error, because nothing here claims durability) and an alternative shape (align with MetadataManager.get() 丢弃 loadDiagnosed 的 degraded 判定:loader 读不到与「这一项没声明」在 6 个消费点上不可分辨 #5840's getDiagnosed, pushing the verdict to the caller). Picking between those is implementation judgment, not a contract change.

Why the gate never catches it, which is the part worth carrying into the fix: check-durability-degradation-log-level.mjs's read-seam-invention rule (#5186) scans for fabricated empty answers; returning the input argument unchanged is outside that vocabulary. Whoever implements this should say in the PR whether the gate's vocabulary should grow to cover "returns the input unchanged" — if it should, that is a separate devx issue, not a rider (the gate lives in scripts/, a different lane).

Already adjudicated, do not re-litigate: the neighbouring engine.ts:3870 catch → return { verified: false, conclusive: false } is explicit tri-state and stands — the body recorded that verdict precisely so the next sweep does not re-open it. Leave it alone.

Serialization: engine.ts is a hot shared file. #6063 is already noted as hard-serialized behind PR #6013 on this same file, and PR #6114 (#5979) is the PR this was found beside. Name the predecessors in the claim comment and check git log origin/main -- packages/objectql/src/engine.ts at claim time.

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

---

Generated by Claude Code

[baozhoutao]

认领(engine-core 席 #6019,会话 session_019Q7oc7ASjh8yxyS3Yz78We,第 16 轮):

• 分支:claude/issue-6116-sys-file-hydrate-fault
• 工作树:../objectstack-6116
• 文件面:packages/objectql/src/engine.ts(仅 sys_file hydrate 读路径的 catch 位)+ 对应测试 + changeset。
• engine.ts 串行链前驱(分诊要求点名):PR fix(objectql): multi update 的 SET 载荷剥掉非 id 的 data.id (#6262) #6433(data.id 是算子对象 + multi: true 时,{"$in":[...]} 作为普通列进入 updateMany 的 SET 载荷,写向主键列 #6262,19:01Z MERGED)→ PR fix(objectql,lint): 服务端为 requiredWhen 绑定 parent 作用域,并把构建期硬闸扩到同一格 (#4977) #6440(Parent-scoped requiredWhen is unenforced server-side — the same gap #4889 closed for readonlyWhen, one slot over #4977,20:44Z MERGED,本席刚落地)。当前链上无在飞占用,认领时已核 git log origin/main。
• 执行口径:按分诊 08-07 02:59Z 晋级评论 —— 验收一句话:「非良性的 hydrate 读故障必须与『无文件』可分辨」;fail-open 行为不变,这是可诊断性修复。最小形(isMissingTableError 判别 + 非良性 warn,不升 error)与 MetadataManager.get() 丢弃 loadDiagnosed 的 degraded 判定:loader 读不到与「这一项没声明」在 6 个消费点上不可分辨 #5840 getDiagnosed 形对齐二选一属实现判断,PR 里说明取舍。⛔ 不触 :3870 已裁定的显式三态;闸门词表是否该扩为独立 devx 单,PR 里表态、不夹带。
• 标签对:pm:queue → pm:dispatched 同步落。

---

Generated by Claude Code