Skip to content

metadata-admin DOM tests: two surfaces that never settle under the light dom project, with no diagnostic #4249

Description

@yinlianghui

Observation-class finding, measured while writing objectui#4132's pins (PR #4248). Nothing a user hits — this is a test-harness characteristic. Recording it because both specimens present identically (the test file produces no output at all and never exits), which is the most expensive failure shape to diagnose from scratch: there is no timeout message, no failing assertion, no partial reporter output, and --reporter=verbose does not help because it flushes per file.

Specimen 1 — a component that opens a Radix Sheet

Rendering MetadataDetailDrawer (which wraps its body in Sheet / SheetContent) inside the dom project ran past 540s with zero output. The component it hosts renders on its own in ~6s:

renderresult
< MetadataDetailDrawer target={embedded} … >no output, killed at 540s
< EmbeddedItemEditor … > (the entirety of the drawer's embedded branch)8 tests, 6.7s

Consistent with the repo's own layout: the only test that renders an open Sheetlayout/__tests__/ChatDock.test.tsx — is in heavyDomTests (i.e. the dom-heavy project with the full setup). The two other light-project files that mentionSheet do not render one: preview/__tests__/CommitTimeline.test.tsx names it in a comment, and views/studio-design/__tests__/studioChatDockPersistence.test.tsx mocks it away (ChatDockMobileSheet: () => null).

Specimen 2 — a SchemaForm whose schema declares a condition property

SchemaForm.tsx:344 (CONDITION_FIELD_NAMES) routes visible / hidden / disabled / visibleOn / condition / predicate / *When to the CEL ConditionWidget, whose formula loader is a dynamic import (celAuthoring.__setCelFormulaLoader). Bisected one property at a time against an otherwise identical fixture:

schema property addedresult
namerenders, 43ms
labelrenders, 44ms
conditionno output, killed

This is the unbounded-module-load trap AGENTS.md §测试纪律 already describes, reached through a schema key name rather than through an obvious React.lazy in the component under test — which is why it is not obvious from the test's own source that a dynamic import is involved at all.

Why it is worth writing down rather than fixing here

Both are avoidable once known, and #4132 avoided both (mount the hosted component directly; keep the routed key out of the fixture's schema — the value is still asserted, on the preview that reads it off the draft). Neither is a defect in the product code, and neither should be "fixed" by parking a file in heavyDomTests — AGENTS.md restricts that list to registry <type> not registered failures and explicitly rejects it as a flake remedy.

Possible dispositions, none obviously right, hence finding and not pm:queue:

Provenance

Measured on branch claude/issue-4132-retire-standalone-validation at 733935e3, container-shared runner, pnpm exec vitest run <file> --maxWorkers=2 from the repo root. Related: #2648 (closed — the DOM project split these two specimens land on).


Generated by Claude Code

Metadata

Metadata

Assignees

No one assigned

    Labels

    domain:devxobjectui devx stream: fix lands on .github/, scripts/ or release pipeline — devx lane cross-repopm:on-hold

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions