[finding] `object-form` 与 `object-master-detail-form` 在 binding-reach 探针的自动 fixture 下渲染成错误卡(`reading 'map'`)—— 断言仍成立,但两个分支的崩溃守卫因此没法一起开

[yinlianghui]

发现于 #3808 的实施过程:给 public-block-binding-reach.test.tsx 的 ledgered 分支加崩溃守卫时,顺手把守卫加到了两个分支上,于是这两个块立刻红了 —— 它们一直在这个探针里渲染成错误卡,只是没人看。#3808 的 PR 已把守卫收窄回 ledgered 分支(那才是它的改动可能造成的空绿),这两条另记本单。

按 observation-class 只贴 finding、不排队:这两个块的断言本身仍然成立(见下),所以今天没有假绿,请 triage 决定是产品缺陷还是 fixture 缺陷。

事实(objectui origin/main @ c85268256 + #3808 分支)

apps/console/src/__tests__/public-block-binding-reach.test.tsx 用 sampleFor 按每个 block 声明的 inputs 自动填一份 schema,然后挂载并记录数据层调用。把「渲染没崩」这一条也断言上之后:

× object-form asks the data layer for its objectName
  <object-form> threw during render …
  Component "object-form" failed to render
  Cannot read properties of undefined (reading 'map')

× object-master-detail-form asks the data layer for its objectName
  Component "object-master-detail-form" failed to render
  Cannot read properties of undefined (reading 'map')

其余 14 个候选块全部渲染正常。

为什么今天不是假绿

这两个块不在 NO_DATA_REACH 里,所以它们走的是「必须有数据调用」那一支:

expect(reached.length, …).toBeGreaterThan(0);

实测它们确实发出了带 PROBE_OBJECT 的调用 —— 崩溃发生在取到数据之后的某一趟渲染里,不是在 fetch 之前。所以断言是挣来的,不是靠「什么都没产出」蒙的。

对比 ledgered 分支(如 record:related_list)就完全不同:那里的通过条件是「没有数据调用」,一个崩掉的块恰好满足它 —— 那才是必须堵的空绿,#3808 堵的就是那一处。

两种可能,需要 triage 分辨

• (a) fixture 缺陷。这个探针的头注释已经记了四次同一个教训:「a plausible value for EVERY input is not the same as a plausible CONFIGURATION」(columns: [] 让列表走空态不 fetch;裸 Proxy 被 spread 后丢掉所有方法;sections: ['name'] 被 spread 成 {0:'n',1:'a'} 后在 DetailView 里死于 reading 'name')。reading 'map' 的形状高度相似 —— 某个 array 输入被填成 ['name'],而 form 侧期待的是对象数组,于是在某处 .map 前先取了个 undefined。若是这一类,修法是给该 input 一个像样的样本,并把它加进这个文件的样本表 + 头注释(第五、第六次)。
• (b) 产品缺陷。form 家族在某个合法但不完整的配置下裸取了一层。若是这一类,和 record:related_list 写了 add 但漏了 add.picker,整个相关列表被换成「Component failed to render」错误卡 —— RelatedList.tsx:1299 裸取 add.picker.object,同一文件 :378/:390 是可选链 #3838(RelatedList.tsx:1299 裸取 add.picker.object)是同一族:一个可选子键缺失,整块变错误卡。

分辨成本很低:把 sampleFor 生成的 schema 打出来,逐个 input 换成 undefined 二分,定位到具体那一条,再看该 input 的 spec 形状是不是允许样本那种值。

附带的建议

无论 (a) 还是 (b),这个探针最终都应该像它的兄弟 record-block-record-reach.test.tsx 那样对两个分支都断言「渲染没崩」(那个文件里叫 assertRendered)。现在只有 ledgered 分支有,是因为 #3808 不该把两个 pre-existing 崩溃拖进一个补 inputs 声明的 PR。这两条修掉之后,守卫就可以提到断言之前、对所有候选生效。

参考位置

• apps/console/src/__tests__/public-block-binding-reach.test.tsx —— sampleFor(样本生成)、dataCallsFor(现在会把 html 一起带出来)、ledgered 分支的崩溃守卫
• apps/console/src/__tests__/record-block-record-reach.test.tsx —— assertRendered,两分支通用守卫的现成形状

关联:#3808、#3838、#3149、objectstack#4472、objectstack#4413

[claude]

Findings round: PROMOTED — finding → pm:queue.

• The body's fork (fixture defect vs product defect) is dev-measurable at trivial cost (print the generated schema, bisect inputs), and both outcomes are concrete scoped work: extend the probe's sample table (the file's own lesson list, 5th/6th entry) or fix a bare take in the form family — the latter the same class as record:related_list 写了 add 但漏了 add.picker,整个相关列表被换成「Component failed to render」错误卡 —— RelatedList.tsx:1299 裸取 add.picker.object,同一文件 :378/:390 是可选链 #3838, queued this round. Either way the probe ends with assertRendered on both branches (existing shape in record-block-record-reach.test.tsx).
• Repro is exact: guard the non-ledgered branch and the two blocks go red with reading-map TypeErrors, while their data-reach assertions still pass (so today there is no false green — the crash is post-fetch).
• Stale-premise: probe file + object-master-detail-form verified on origin/main @ f5f8744; measurements are hours old (parity 门的反方向没推到全仓:7 个 block 共 15 个 spec 已声明的顶层键没有任何 inputs 发布,其中 3 个渲染器实读(record:details.hideFields / record:related_list.relationshipValueField / element:text_input.defaultValue) #3808 branch).

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-warren]

Claim: PM loop round 3
Session: session_01PQ3NihCHE9LUtHoGxo6A9f
Branch: claude/issue-3840-binding-reach-form-crash
Worktree: objectui-issue-3840
Domain: domain:devx (@ objectui, seat #5748)
File surface: apps/console/src/__tests__/public-block-binding-reach.test.tsx; plus, only if the fork below resolves to (b), the one renderer that bare-takes — name it in the report before you edit it. (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus — the fork is a judgement call, not a mechanical edit. ⚠️ scripts/pm/dispatch-gates.mjs is objectstack-resident; objectui has no scripts/pm/, so this tier is this seat's explicit per-card decision, ⛔ not a --tier reading that does not exist here.
Clause-②: no — a test fixture and at most one bare take. No contract acceptance behaviour moves, no public surface grows.
Serial constraints cleared: no open PR touches the probe file. Repo-wide open PRs read by head at claim time — #5925 (packages/app-shell/src/preview/DraftChangesPanel.tsx, comment-only), #5922 (layout docs), #5843 (docs/adr, governed), #5774 (.github/workflows/ + ci-cd-pipeline.md), #5400 (release), #4958 (dependabot) — none intersect. Concurrent in this same batch: #5458, which touches apps/console/src/sdui-workbench-preview.tsx and two packages/app-shell/src/views/** files — disjoint from this card's surface by file, but if your fork lands on (b) in a shared renderer, stop and report rather than editing across it.

Premise re-verified on origin/main @ 2074a59, and it holds

⛔ Not inherited from the card, which is 16 days old. Measured now:

• The probe file is present, 453 lines.
• Its ledgered branch carries the crash guard (html.includes('failed to render') → toBe(false)), and the non-ledgered branch still does not.
• The code names this card by number. Verbatim from the comment block above the guard: "Deliberately NOT applied to the other branch: object-form and object-master-detail-form do paint an error card under this fixture (Cannot read properties of undefined (reading 'map')) while still making their data calls, so their verdicts are earned rather than vacuous. Whether that card is a product bug or this fixture handing them an implausible configuration — the lesson the header records four instances of — is objectui#3840, not something to decide by widening a guard here."

So the card is live, and main is explicitly waiting on it.

What you are deciding — the fork is the card

Do not widen the guard first and see what breaks. Resolve which of these it is, with a measurement:

• (a) fixture defect. sampleFor hands the form family a plausible value for every input that is not a plausible configuration. The probe's header already records four instances of exactly this lesson (columns: [] short-circuiting the list; a bare Proxy losing its methods when spread; sections: ['name'] spreading to {0:'n',1:'a'} and dying in DetailView). reading 'map' fits the shape: an array input filled with ['name'] where the form expects an array of objects. Fix = a decent sample plus the fifth/sixth entry in that header's lesson list.
• (b) product defect. The form family bare-takes one level under a legal-but-incomplete configuration. Same family as record:related_list 写了 add 但漏了 add.picker,整个相关列表被换成「Component failed to render」错误卡 —— RelatedList.tsx:1299 裸取 add.picker.object,同一文件 :378/:390 是可选链 #3838 (RelatedList.tsx bare-taking add.picker.object).

The card names the cheap discriminator and it is still right: print the schema sampleFor generates, then bisect the inputs to undefined until the crash moves. That names the input; then read whether the spec shape for that input actually permits the sample's value. That last step is what separates (a) from (b) — ⛔ do not stop at "the crash went away when I changed the sample", which is true under both readings.

The endpoint, once the two blocks are green

Both branches assert render, the way the sibling probe record-block-record-reach.test.tsx already does with assertRendered. The guard moves ahead of the branch split and applies to all 16 candidates. That is the durable half — today the probe can only catch a crash on the branch where a crash is the pass condition.

PM mechanism assumptions — test these, do not trust them

Rank-ordered as assumptions, ⛔ not rulings, and I would rather be shown wrong than have you build on them:

1. I read (a) as more likely than (b), on the base rate of that header's four prior entries. Weak. The card's author, who had the file open, deliberately left it 50/50.
2. reading 'map' reads like an array-shaped input. Also weak — it could equally be a nested object the renderer maps over after a take.

Premise-first

The issue body is a lead, not a specification. If the two blocks no longer crash on today's main — someone may have fixed the renderer meanwhile — that is a legitimate and valuable delivery: report premise_still_valid: false with the measurement, open no PR, and say what changed. ⛔ Do not manufacture a diff to have something to show. Equally, if you find the fork resolves to (b) and the fix is larger than one bare take, stop and report rather than widening.

Read the card's full body and every comment on GitHub yourself, and check the body for sanitizer truncation before you rely on it.

---

Generated by Claude Code