census(finding): three more renderer fetch effects key on a memoised object identity, outside objectui#6592's dataConfig family

[os-sales]

Origin: objectui#6592's census (systematic sweep of every useEffect whose dependency array names a useMemo-bound identifier, cross-checked against a fetch-call-site heuristic, positive-controlled against the known packages/plugin-map member). That card's fix is scoped to the getDataConfig(schema)-into-useMemo family (plugin-map, plugin-calendar, plugin-gantt, and plugin-tree/plugin-grid — the latter two deferred/fenced separately). The sweep also surfaced three renderer effects outside that family with the same structural hazard, reported here rather than folded into #6592's diff to keep that PR scoped to its named family.

The shared hazard (background, not new)

useMemo carries no semantic guarantee — React may discard a memo's cache and recompute it even when the dependency array compares equal to the previous render. A fetch effect (or a count-probing effect that calls dataSource.find) whose OWN dependency array names the memoised object itself, rather than the primitive fields it reads off that object, therefore refetches on a discard even though nothing an author or caller controls changed. objectui#6018/#5976/#6591/#6592 is the multi-round campaign fixing this for the dataConfig/mapConfig/schema family specifically; these three are the same shape, different origin.

1. packages/plugin-detail/src/RelatedList.tsx — defaultSortSpec / listFilterNode

const defaultSortSpec = React.useMemo(() => normalizeSortSpec(defaultSort), [defaultSortKey]);
const listFilterNode = React.useMemo(() => toFilterNode(filter), [filterKey]);

Both are already keyed on a JSON.stringify-derived string (defaultSortKey/filterKey) rather than on defaultSort/filter directly — which protects against a render-fresh defaultSort/filter prop, but NOT against useMemo discarding its cache and calling normalizeSortSpec/toFilterNode again, which is free to return a new object even when the key matched. The fetch effect further down lists defaultSortSpec/listFilterNode themselves (not the string keys) in its own dependency array.

2. packages/components/src/renderers/layout/containers.tsx — probeTargets

const probeTargets = React.useMemo(() => { /* builds a Map(...) */ }, [items, recordObject]);

probeTargets is a Map, consumed by identity in the related-count-probing useEffect right below it (if (probeTargets.size === 0) return; for (const probes of probeTargets.values()) { ... ds.find(...) }). A discard reconstructs an equal-content Map with a new identity and re-probes every tab's count.

3. packages/plugin-list/src/ListView.tsx — expandFields

const expandFields = React.useMemo(() => { /* string[] derived from schema.columns */ }, [...]);

Consumed by identity in the $expand-building fetch effect. Not fully triaged against a positive/negative discard-proxy test the way #6592's four fixed files are — flagging for someone to do that triage before treating it as confirmed, since ListView is large, central plumbing and a false positive here would be costly to chase.

Severity

Low — the observable is an extra dataSource.find/count-probe round trip on a memo-cache discard, not incorrect data (unlike #5953/#6014-class bugs, nothing here is a value-equality trap). Worth fixing on the same "useMemo is a pure optimisation, not a correctness dependency" principle #6592 is closing out, not urgent.

Unassigned — filed as a census finding for triage to route, not claimed.

[os-sales]

Claim: domain:ui execution seat, session session_01CRJge11jso9TpXRWFt1Z49, branch claude/issue-6697-memo-identity-fetch-effects.

Dispatch order

type: Task, priority:p2. Card filed by this seat off #6592's census — ⭐ re-derive from the code; do not trust its line references as measured-now.

This continues a family this seat has landed twice (#6698 for plugin-map/-calendar/-gantt, #6701 for plugin-tree). The principle is settled: useMemo is a pure optimisation, not a correctness dependency — React may discard a cache and recompute even when deps compare equal, so a fetch effect keyed on the memoised object refetches on a discard.

The three members — ⚠️ they are NOT equally confirmed

#	site	status
1	plugin-detail/src/RelatedList.tsx — defaultSortSpec / listFilterNode	confirmed shape
2	components/src/renderers/layout/containers.tsx — probeTargets (a Map, consumed by identity in the count-probing effect)	confirmed shape
3	plugin-list/src/ListView.tsx — expandFields	⛔ NOT confirmed

⛔⛔ Item 3 is fenced by the card's own words:

Not fully triaged against a positive/negative discard-proxy test the way #6592's four fixed files are — flagging for someone to do that triage before treating it as confirmed, since ListView is large, central plumbing and a false positive here would be costly to chase.

⇒ Triage item 3 before touching it. If the discard-proxy test shows it is a false positive, say so and leave it alone — a reported non-member is a good outcome, not a failed one. Fix items 1 and 2 regardless.

⭐ The trap this family has already sprung once

#6592 predicted four discard-pins red pre-fix; ObjectCalendar's passed even pre-fix, because that component's memo was already primitive-keyed by #6018 — the trigger never recomputed. A pin that cannot fail is indistinguishable from a working guard.

⇒ Choose each trigger against that component's actual memo and prove it discriminates PRE-FIX. Item 1 is the live risk here: defaultSortSpec/listFilterNode are already keyed on JSON.stringify-derived strings, which protects against a fresh prop but not against a discard. So a trigger that varies the prop may well not discriminate — you need one that forces the discard path, or an equivalent proxy.

⛔ The useRef / stable-identity hack stays forbidden (#6018 ruling).

Severity — read it, and let it shape the fix

The card rates this Low: the observable is an extra dataSource.find / count-probe round trip on a discard, not incorrect data. ⛔ So do not widen this into a correctness refactor. Re-key the effects onto the primitives they actually read; nothing more.

Adjacent work — no file collision, but know it exists

#6677 is in flight on plugin-grid's column derivation, and its story involves ListView as the fetching host. Different package, different concern, no shared file — but if your item-3 triage takes you into ListView's fetch path, check that card before assuming a reading is yours.

Report: the item-3 triage verdict first, then red-before/green-after per fixed member, and your changeset score with reasoning.

---

Generated by Claude Code