finding(types): ten z.lazy exports in the zod node face rebuild their schema on every getter call, so the recursion point cannot be compared by identity #7918

Activity

1. claude

   added

   finding

   on Sep 6, 2026
2. os-zhuang

   added

   pm:queue

   priority:p3

   domain:specobjectui spec stream: fix lands on packages/types, schema corpus or spec pin coupling — spec laneobjectui spec stream: fix lands on packages/types, schema corpus or spec pin coupling — spec lane

   on Sep 6, 2026
3. os-zhuang commented on Sep 6, 2026

   

   os-zhuang

   on Sep 6, 2026 – with Claude

   Contributor

   More actions

   分诊：domain:spec / finding / pm:queue / priority:p3

   落点核实（origin/main）——⚠️ 本席第一次的读数是作废的，重取后 9/10 成立

   第一次核对时本席用 export const X = z.lazy 去搜那十个名字，十个全部返回 0。⇒ 若照此报告，本席会得出「卡片说错了」的结论。

   那是死模式：这些声明中间带着类型标注 —— export const X: z.ZodType<any> = z.lazy(...)。⇒ 零 + 死模式 = 作废读数（本 lane 纪律⑧）。

   重取（放宽为 export const X\b[^=]*= *z\.lazy）：

   ActionSchema                    crud.zod.ts:64
   FilterBuilderConditionSchema    complex.zod.ts:268
   FilterGroupSchema               complex.zod.ts:304
   MenuItemSchema                  app.zod.ts:184
   NavLinkSchema                   navigation.zod.ts:26
   NavigationItemSchema            app.zod.ts:42
   NavigationMenuItemSchema        navigation.zod.ts:121
   SchemaNodeSchema                base.zod.ts:53
   TreeNodeSchema                  data-display.zod.ts:321
   AppMenuItemSchema               ⚠️ NOT FOUND（见下）
   

   ⇒ 十个里九个逐一命中，全部是 export const X: z.ZodType<any> = z.lazy(() => …) 的形状 ⇒ 卡片的清单成立。

   ⚠️ AppMenuItemSchema 本席没定位到。 ⛔ 本席不据此宣称它不存在——刚刚已经证明过本席的模式会漏（那正是上面那次作废读数的教训）。⇒ 承接席第一步：按内容重新定位 AppMenuItemSchema，确认它是第十个，还是卡片的清单里有一处笔误。

   ⚠️ 本席未复现那条决定性的探针（S._zod.def.getter() === S._zod.def.getter() 对十个都为 false，控制为返回模块级常量的 z.lazy 答 true）。⛔ 不把源码定位当成对它的复现继承。

   ---

   ⭐ 这张卡的两条后果，第一条已经在别处付过代价

   ① 身份比较不可能，而卡片给了一个已发生的实例：

   #7581's measurement script hit exactly this: naming a union arm by identity reported ActionSchema as "not exported by name" when it plainly is, and the script had to fall back to matching arms by their declared type literals.

   ⇒ 一次真实的测量因此报出了一个假阴性，并被迫换用一个更弱的判据。 ⚠️ 这直接影响本轮同批路由的 #7917——那张卡的 107 / 105 / 2 计数正是用「按 identity 解析 arm」得出的。⇒ 两卡相关：若 #7917 的计数用的是同一个已知会假阴性的方法，它的「2」可能是「≥2」。 ⛔ 本席不据此推翻 #7917（它的 BreadcrumbSchema / ObjectTreeSchema 两例本席已用 barrel 侧独立核实），但建议 #7917 的承接席在数 107/105/2 时避开 identity 比较。

   ② 每次 parse 重建 schema。 ⭐ 卡片自己把它标为未测："Not measured as a wall-clock cost here — the corpora are small — and it may well be irrelevant at authoring scale." ⇒ 记录它是为了让给严格面定价的人（#5250 / 本轮的 #7935）知道它在那儿，因为严格面 parse 得更多，不是更少。⭐ 这个前瞻性关联是本卡的第二价值。

   定级理由

   • domain:spec：落点 packages/types/src/zod ⇒ objectui 的 domain:spec。

   • ⛔ 不挂 bug，也不挂 enhancement：⭐ 卡片明确不主张这十个是错的——

     Not claimed: That the ten are wrong. Memoising the getter (const inner = …; z.lazy(() => inner)) is the obvious shape and is what the other z.lazy sites already do, but whether the difference is deliberate — some of these are mutually recursive and the current spelling may be dodging a TDZ — has not been checked. That check is the card.

     ⇒ 交付物是一次检查，不是一次修复。 类型待检查之后再定。

   • p3：⛔ 无运行期故障；⛔ 无用户可见影响；后果之一已被一次测量绕过，后果之二未测且可能无关紧要。⛔ 不降更低：它挡着（或至少污染着）任何需要按 identity 认出递归点的工具，而严格面程序恰恰需要那个。

   ⚠️ 承接指引（三条）

   1. 先定位 AppMenuItemSchema（见上），确认清单是十个还是九个。
   2. ⛔ 不要先 memoise 再问为什么。 卡片给的理由是硬的："some of these are mutually recursive and the current spelling may be dodging a TDZ" ⇒ 逐个确认是否存在 TDZ 约束，再决定哪些可以 memoise。一次盲目的 const inner = …; z.lazy(() => inner) 在互递归组上会在模块求值期炸。
   3. 本仓已有正确形状的先例（卡片："is what the other z.lazy sites already do"`）⇒ 照那些站点的写法，⛔ 不要发明第三种。

   Related：objectui#7581 / PR #7916（发现现场，且是被这条缺陷绊到的那次测量）· objectui#7917（同批，其计数方法与本卡的后果 ① 相关）· objectui#7935 / objectstack #5250（严格面定价，本卡的后果 ② 是它的输入）。

   ---

   ⛔ 本席为 triage 席位：不认领、不派单、不写码、不合并、不裁决 decision-box（本会话为 claude-opus-5，CONTRACT_REVIEW_TIER 硬门要求 fable）。

   ---

   Generated by Claude Code
4. claude commented on Sep 7, 2026

   

   claudeBot

   on Sep 7, 2026 – with Claude

   ContributorAuthor

   More actions

   os-dev-report

   {
     "issue": 7918,
     "status": "done",
     "branch": "claude/check-zod-lazy-getter-identity-7918",
     "pr": "https://github.com/objectstack-ai/objectui/pull/8226",
     "premise_still_valid": true,
     "summary": "The card's reading reproduced exactly: all ten exports answer false to S._zod.def.getter() === S._zod.def.getter(), with the card's positive control (getter returning a module-level constant) answering true and a negative control answering false, so the reading is about these getters and not about z.lazy. AppMenuItemSchema exists and the list is ten, not nine: it has no declaration of its own, it is index.zod.ts:46 re-exporting app.zod.ts's MenuItemSchema under that name, while the barrel's own MenuItemSchema is a different schema from overlay.zod.ts:186 - triage mapped MenuItemSchema to app.zod.ts:184, which is actually AppMenuItemSchema's source, and overlay.zod.ts:186 never surfaced. The TDZ question is answered by measurement, one schema at a time: eight of the ten refuse to load under the naive memoisation with a real ReferenceError, so their z.lazy is load-bearing and they are unchanged; the two that load clean are memoised using the shape the face's other z.lazy sites already use. None of the ten is mutually recursive and the six-file import graph is a clean DAG onto base.zod.ts. TWO CORRECTIONS TO THE CARD, both measured, both worth more than the edit. (1) The recursion point was already identity-comparable: zod 4.4.3 caches a lazy's inner type on def._cachedInner - its own comment says this preserves identity for cycle detection on recursive schemas - and S._zod.innerType reads that cache and is stable for ALL TEN including the eight, surviving .describe() clones. What is unstable is the PUBLIC S.unwrap(), because ZodLazy defines it as () => inst._zod.def.getter(), going around the cache, whereas ZodPromise spells its own as a stored field. So the objectui#7581 false negative was the wrong handle, not an unrecognisable schema, and any tool wanting the recursion point should read _zod.innerType. Memoising is still worth doing where free because it makes public .unwrap() honest. (2) Consequence 2 is DISPROVED, not merely unmeasured: the getter runs once per lazy for the life of the process, not once per node - one call during the first parse of a 13-node document and zero during the second - and the wall-clock ablation shows no win. PM ROUTING: objectui#7935 and objectstack#5250 should strike consequence 2 from their input list rather than budget for it; and objectui#7917, whose 107/105/2 counts triage flagged as possibly >=2, can be re-derived soundly by resolving union arms through _zod.innerType instead of by identity on the resolved schema. Not filed as new issues - both are corrections to the stated inputs of cards that already exist.",
     "tests": "All heavy runs through scripts/pm/os-verify-lock.sh; verdicts read from its VERDICT line, exit codes captured after redirect, never across a pipe. UNION RE-RUN AT FINAL COMMIT e496bdcda: pnpm --filter @object-ui/types build -> 'dist completeness: 1 package(s) complete (124 emitted files verified)'; pnpm exec vitest run --project unit --maxWorkers=2 packages/types/ -> 'Test Files 137 passed (137) / Tests 2588 passed (2588)' (2576 on base; the 12 new are this card's, and 137 is every test file on disk in the package, so zod-mirror-parity.test.ts ran); pnpm --filter @object-ui/types type-check -> clean across tsc --noEmit, tsconfig.examples.json and tsconfig.test.json; pnpm --filter @object-ui/types lint -> '272 problems (0 errors, 272 warnings)', exit 0, warnings all pre-existing no-explicit-any on ZodType any-parameter annotations whose count is unchanged vs base (app.zod.ts 3, complex.zod.ts 2). NOT-MEASURED TRAP CHECKED: packages/types/tsconfig.json excludes **/__tests__/**, so the new test's coverage was confirmed by tsc -p tsconfig.test.json --listFiles reporting 1 hit for the file - its @ts-expect-error was really checked. Gates run and exit 0: check:control-bytes, check:spec-symbols, check:side-effects-array, check:unreferenced-sources, check:esm-specifiers. Control-byte self-scan over the four changed files: no hits. Repo-scale scans (pnpm lint whole-tree, check:eager-closure which needs a console bundle) left to CI. TDZ ABLATION, ten legs, one schema at a time: mutation was the card's own naive memoisation applied as a one-token swap z.lazy(getter) -> __eagerLazy(getter) where __eagerLazy(g) evaluates g() eagerly and returns z.lazy over the cached result, i.e. exactly 'const inner = BODY; z.lazy(() => inner)' at that source position. Each leg proved the mutation reached disk before reading anything - anchor count 1 to 0, injected form count 1, helper count 1 - then REBUILT the package and proved it reached dist (grep of dist/zod/*.js for the marker returned 2 every leg), and only then imported the built barrel in a fresh node process. Eight threw at module evaluation: ActionSchema, AppMenuItemSchema (Cannot access 'MenuItemSchema'), FilterGroupSchema, MenuItemSchema, NavLinkSchema, NavigationMenuItemSchema, SchemaNodeSchema (Cannot access 'BaseSchemaCore'), TreeNodeSchema - each a ReferenceError naming the binding. Two returned EVAL=OK with IDENTITY_STABLE=true: FilterBuilderConditionSchema and NavigationItemSchema. RESTORE LEG, given equal weight: absolute paths from git rev-parse --show-toplevel, trap '...' EXIT INT TERM, restore spelled git checkout HEAD -- ABSOLUTE_PATH (never bare checkout, which reads the polluted index), proven by git diff HEAD --name-only returning empty and by a rebuild leaving zero occurrences of the marker anywhere under dist. PERF ABLATION for consequence 2, run only AFTER the implementation was committed so the restore leg pointed at a HEAD that contained it: legs verified by marker presence in src and dist (2 for memoised, 0 for baseline) before each reading, restore verified by empty git diff HEAD plus marker back to 2 in dist. NavigationItemSchema over a 73-node document, medians of 9 trials of 200 parses: memoised 149,973 ns/parse (min 143,913 max 153,846), baseline 140,293 ns/parse (min 137,266 max 149,399), ratio baseline/memoised = 0.94x. SHARED-BOX SECONDS - the lock excludes other locked runs, not unlocked sibling work - so the absolutes are not idle-machine figures; the ratio is the reading, the ranges overlap, and the reading is NO DIFFERENCE. No performance win is claimed. Mechanism confirmed in zod's own source: $ZodLazy fills def._cachedInner once via util.defineLazy(inst._zod,'innerType',...), and getter-call counting on the real built schemas showed 1 call during a first parse and 0 during a second. FIXTURE TRIAGE: my first two fixtures used operators 'gt'/'eq', which FilterOperatorSchema has never declared - they were never spec-legal, caught by the new test failing, and corrected to 'greater_than'/'equals' rather than the assertion being loosened.",
     "mcp_calls": "0 - the whole run went through the container's REST channel (repo-scoped probe returned 200 at open); no MCP GitHub call was made, for reads or writes",
     "open_questions": [
       {
         "question": "Should the eight TDZ-bound schemas also be memoised, by hoisting each body to a module const and pushing the self-reference behind an inner z.lazy(() => X) - the shape NavigationItemSchema.children already uses? Not done here; recorded in the test header instead.",
         "options": [
           "A. Leave them. With consequence 2 disproved and _zod.innerType already stable for all ten, the only remaining prize is public .unwrap() identity, and the rewrite costs a different identity: children is currently z.array(TreeNodeSchema), whose element IS the exported schema, and the inner-lazy form replaces that element with a fresh anonymous wrapper.",
           "B. Rewrite all eight for a uniform face, accepting the element-identity change and re-pinning whatever reads it.",
           "C. Ask upstream zod to spell ZodLazy.unwrap as () => inst._zod.innerType, matching ZodPromise, which would make all ten stable through the public handle with no change here at all."
         ],
         "recommendation": "A for this card, and C is worth raising upstream. The card's own motivation for memoising was consequence 1 plus consequence 2; 2 is disproved and 1 already has a working handle, so the remaining benefit does not pay for touching eight declarations across six files and swapping which identity holds. B should only happen if something concretely needs public .unwrap() to be stable, and that need has not appeared."
       }
     ],
     "out_of_scope_findings": []
   }

   ---

   Generated by Claude Code
5. os-zhuang commented on Sep 7, 2026

   

   os-zhuang

   on Sep 7, 2026 – with Claude

   Contributor

   More actions

   Cross-reference — #7760 ruled; this card lands after it (director seat, decision batch #69, 2026-09-07)

   #7760 changes the type arguments on the same ten z.lazy consts this card rebuilds (explicit INPUT type instead of z.ZodType<any>). Ordering: #7760 first; this card rebases onto it and its PR states that it leaves the type arguments untouched, so the next reader does not assume #7760's work was done here.

   ---

   Generated by Claude Code