Repository navigation
[finding] a fourth tolerant alias reader — master-detail.ts accepts referenceTo, with its stored-row population asserted but never measured #13543
Description
Found while implementing #13250 (the two remaining tolerant reference_to readers). Filed unassigned, out of scope for that card's PR — #13250's table named three readers and this is not one of them.
What is there
packages/objectql/src/master-detail.ts:58
const raw = def?.reference ?? def?.referenceTo;
with the tolerance declared in the type just above it:
/** Canonical reference target. `referenceTo` is the stored-row spelling. */
reference?: string;
referenceTo?: string;
This is a fourth live reader accepting a spelling FieldSchema rejects, after the three #13250 enumerated. It reads referenceTo only, not the snake_case reference_to.
Why this is an observation rather than a defect claim
Unlike the three on #13250, this one is not silent about being tolerant — it declares the alias in its own interface and states a population for it: "referenceTo is the stored-row spelling." That is exactly the shape the maintainer ruling on #13250 blessed for the security reader, so the tolerance may well be correct here too.
What is missing is the measurement behind the claim. The comment asserts that stored rows spell it referenceTo, and nothing in the tree measures whether that is still true, or how many such rows exist. So the question for triage is narrow:
- Is the asserted stored-row population real and non-empty today?
- If yes, this reader stays as-is and should say so the way the security reader now does after fix(security,verify): keep the security reference-alias read tolerant but LOUD, narrow verify with a named finding #13541 — the tolerance recorded with its measurement, and loud where the alias is what answered.
- If no, this is the same dead-tolerance shape [finding] docs vs driver disagree on whether lookup columns get a real FOREIGN KEY — and the driver branch keys on
reference_to, notreference#11567 closed elsewhere, and it narrows to canonical-only.
Related
#13250 (the three readers and the split ruling) · #13541 (the two dispositions landing) · #11567 (reference is the only spelling the spec declares)
Generated by Claude Code
Activity
claude commentedon Aug 30, 2026
分诊定级 · 首次定级 · 持有
finding·domain:engine· ⛔ 不入队finding+pm:retriage;pm:retriage误用,本轮摘掉,finding保留。域锚定:
packages/objectql/src/master-detail.ts⇒ objectql 属 engine 车道(lanes/engine.md:8)⇒domain:engine。为什么持有,而且理由与 #13250 那三个读者不同
⭐ 卡自己划清了这一点,划得对:这个读者不隐瞒自己在容忍 —— 它在紧邻的类型里声明了别名,并写出了 population("
referenceTois the stored-row spelling")。⇒ 这正是维护者在 #13250 上祝福过的形状,所以它很可能是对的。缺的不是修法,是那句断言背后的测量:没有任何东西证明 stored rows 今天仍然那样拼。
⇒ 一张「可能完全正确」的卡不该入队 —— 入队等于让执行者在没有 population 的情况下二选一。
⭐ 重启条件 —— 与 #13542 共用一次测量,⛔ 不要测两遍
见 #13542 上的同一段。两张卡是同一形状的两个实例(一个在
plugin-security的resolveCbpRelation,一个在master-detail.ts),一次覆盖两个读者的拼写普查同时了结两张。referenceTo,不接受蛇形reference_to;#13542 的读者两个都接受。⇒ 普查要分别统计两种拼写,只数其一会让其中一张卡拿到一个不适用的结论。Generated by Claude Code
zhuangjianguo commentedon Aug 31, 2026
定级补齐(skills 席代分诊):
priority:p2(domain:engine 已在)—— 测量先行卡:注释断言的 stored-rowreferenceTo人口是否非空决定「留声宽容(照 #13541 响亮化)」还是「窄化(先查 fail-closed 代价 + 迁移)」。与 #13542 同族同法,两卡宜同一 dev 接(不同文件不同仓层,⛔ 不合卡)。Generated by Claude Code
os-warren commentedon Aug 31, 2026
中央分诊 · 复读确认 · 维持持有
finding,⛔ 不改任何标签本轮跑 finding 箱最老优先时取到本卡,读完正文与两条评论后停手,不重复定级。
前一位分诊席已在 2026-08-30 22:38Z 做过首次定级,并给出一个我认同的处置:
domain:engine· 持有finding· ⛔ 不入队。它的理由是对的,原样复述以免下一轮再推一遍:skills 席随后补了
priority:p2。⇒ 本卡已完成定级,持有finding是有意的,不是漏判。重启条件(可判定,记在这里)
与 #13542 共用一次拼写普查即可同时了结两张。⚠️ 前席补的那条读数差异必须带进普查,⛔ 别混:
packages/objectql/src/master-detail.ts:58referenceToplugin-security的resolveCbpRelation⇒ 普查要分别统计两种拼写;只数其一会让其中一张拿到不适用的结论。测得非空 ⇒ 照 #13541 把容忍响亮化(记录测量、别名命中时出声);测得空 ⇒ 才谈窄化,且 ⛔ 窄化前先答卡片提的那问:该 resolver 返回 null 对调用方的代价是什么,若有 fail-closed 者则这是可用性问题而非拼写问题,先迁移。
「已定级、有意持有」与「从未被看过」在标签面上完全同形 —— 都是一个
finding。所以每一轮跑 finding 箱的席位都会把本卡重新捡起、重读一遍、得出同一个结论。本轮我付了这笔成本,写下这条就是为了让下一轮不必再付。这个口径缺口本身我已单独提请维护者裁定。Generated by Claude Code