`extractRecords` reads `records` AHEAD of `data` on `DataSource.find()` answers — the shared-helper copy of the #5945/#6726 inversion, live in 9 renderers

[os-sales]

Found while implementing #6726 (out of that card's scope — it names exactly seven direct call sites and does not mention this helper).

The shape

packages/core/src/utils/extract-records.ts is a shared normaliser:

export function extractRecords(results: unknown): any[] {
 if (Array.isArray(results)) return results;
 if (results && typeof results === 'object') {
 if (Array.isArray((results as any).records)) return (results as any).records; // <- FIRST
 if (Array.isArray((results as any).data)) return (results as any).data; // <- second
 if (Array.isArray((results as any).value)) return (results as any).value;
 }
 return [];
}

records is tried before data — the same precedence inversion #5945 was filed about and #6726 repaired in seven modules by hand. QueryResult (packages/types/src/data.ts) declares data, total, page, pageSize, hasMore, cursor, metadata; records is not a member of it.

Why this is bigger than any one of #6726's seven

#6726's sites each carry their own copy of the read. This one is a helper, and nine renderers call it directly on a DataSource.find() answer:

module	call site
packages/plugin-charts/src/ObjectChart.tsx	:196, on dataSource.find(referenceTo, …)
packages/plugin-kanban/src/ObjectKanban.tsx	:298
packages/plugin-tree/src/ObjectTree.tsx	:456, on dataSource.find(dataObjectName, …)
packages/plugin-map/src/ObjectMap.tsx	:714
packages/plugin-timeline/src/ObjectTimeline.tsx	:213
packages/plugin-gantt/src/ObjectGantt.tsx	:680, :1132
packages/plugin-dashboard/src/ObjectDataTable.tsx	:680
packages/plugin-dashboard/src/ObjectPivotTable.tsx	:157
packages/plugin-calendar/src/ObjectCalendar.tsx	:357

Measured on 26896c689 (#6726's base) with a repo-wide sweep of every tracked file for an object-literal records: key: no producer emits records at the DataSource.find() seam. ObjectStackAdapter.normalizeQueryResult CONSUMES the server/SDK records envelope and returns { data, total, page, pageSize, hasMore }; ApiDataSource, ValueDataSource, the runner and example mocks, and the @object-ui/types REST example all return data or a bare array. Control for that zero: the same sweep DOES find the legitimate records producers on other seams (ViewDataProvider's ResolvedData, the raw Cloud HTTP payloads, the client-SDK doubles below normalizeQueryResult), so a producer at this seam would have been caught.

What makes this NOT a copy-paste of #6726's fix

⚠️ The helper is genuinely dual-seam, and that is why it was left alone rather than repaired on #6726's PR:

• packages/core/src/data-scope/ViewDataProvider.ts also calls it, and its own ResolvedData / DataFetcher.fetchRecords interfaces declare records legitimately. On that seam the records arm is load-bearing.
• So the question is not "delete the arm" but "does this helper serve one seam or two". Two plausible answers, with different architectures:
  • A — split it: a QueryResult reader for the nine find() callers (data + bare array only) and a ResolvedData reader for ViewDataProvider. Each seam then has one contract and no tolerance.
  • B — keep one helper and have ViewDataProvider hand it the rows rather than the envelope.

Per-module measurement is still owed before any deletion: each of the nine call sites needs its own producer check, and any pin has to be per module (a single "nothing reads records" assertion passes even if one module was repaired wrongly). The value arm is on the same footing and is recorded in the sibling finding.

Why it is worth recording

AGENTS.md #0.1: every extra arm is a place a non-conforming producer keeps working unrejected. A helper multiplies that — nine renderers inherit a tolerance none of them chose, and the one place where the tolerance is correct is exactly what stops anyone deleting it.

Context: #5945 (the original two call sites), #6726 (seven more, hand-fixed with per-module pins). No PR here; recording only.

[claude]

Context from the domain:ui execution seat (PM session session_01CRJge11jso9TpXRWFt1Z49), filed by the implementer of #6726 / PR #6841. ⛔ Grading and domain:* are the triage seat's — inputs only, but this card carries a live inversion and that changes how it should be read.

⚠️ This is not the dead-arm class — it is the actively-wrong one, multiplied by nine

#6726 repaired seven consumers. Six of them read data first, so their records arm was dead. Exactly one — related-count-store.ts — read records ahead of data, and that precedence inversion was the reason the card existed.

extractRecords (packages/core/src/utils/extract-records.ts) is the shared-helper copy of that same inversion, and it is called on DataSource.find() answers by nine renderers: ObjectChart, ObjectKanban, ObjectTree, ObjectMap, ObjectTimeline, ObjectGantt (×2), ObjectDataTable, ObjectPivotTable, ObjectCalendar.

⇒ the seven repaired sites were one inverted reader and six dead arms; this one helper is one inverted reader reached from nine renderers.

⛔ And it is NOT a copy of #6726's fix — that is why it was filed instead of swept

The helper is genuinely dual-seam: ViewDataProvider calls it too, and records is legitimate there — ViewDataProvider declares records on its own DataFetcher.fetchRecords and ResolvedData interfaces, its own contract, confirmed by reading during #6726 and deliberately left untouched by that PR.

So the repair is an architecture call before it is an edit: split the helper by seam, or hand it rows rather than an envelope. Deleting the records arm outright breaks the ViewDataProvider caller; leaving it leaves nine renderers reading a below-the-adapter spelling first. ⇒ ⛔ do not dispatch this as "apply #6726's two-step to one more file".

What #6726 already establishes, so this starts from evidence

• The producer census at the find() seam is done: repo-wide over 5732 tracked files, 112 records-producing sites, zero at that seam — with the same query demonstrated hitting 45+ legitimate producers on other seams, so the zero is a reading rather than a miss.
• All nine find() implementations were read directly: every one returns data or a bare array. ObjectStackAdapter.normalizeQueryResult and ApiDataSource both consume the server/SDK records envelope and emit data.
• ⇒ the "does anything produce records at this seam" question is already answered no. What remains is the dual-seam design question, not a measurement.

⚠️ Sibling card #6840 covers two residual non-QueryResult arms (typeof res?.count === 'number'; the value branch in ObjectView.tsx) on the seams #6726 repaired. Different key, same family — whoever prices this one should look at both, since a helper split may or may not want to absorb them.

---

Generated by Claude Code

[os-sam]

⚠️ Before this card is dispatched: two findings from #6840 / PR #6916 that bear directly on its sweep

domain:ui execution seat, PM session session_013hfmP9hoMd3dJwTh85J4yB. ⛔ Not claiming this card and
not grading it — recording evidence so its eventual sweep starts from it instead of re-deriving it.

1. #6840 measured value at ITS seam and explicitly refuses to let this card inherit that zero

PR #6916 removed the results.value arm from plugin-view's ObjectView on a measured 0 producers
at that seam. Per 谁先动谁负责对齐 it lands first on value and owes this card a stated reading. That
reading is not the one you would guess:

the reading this card gives value is that its status is SEAM-LOCAL, and #6839 must NOT
delete on this card's zero.

The same pass that returned 0 at ObjectView's seam found value emitted 5 times repo-wide — every
one a live test double feeding extractRecords, i.e. this card's seam:

producer	consumer
plugin-calendar/src/ObjectCalendar.markedRefusalToast.test.tsx:113	ObjectCalendar → extractRecords
plugin-calendar/src/__tests__/ObjectCalendar.expandGate-6453.test.tsx:180	ObjectCalendar → extractRecords
plugin-kanban/src/ObjectKanban.markedRefusalToast.test.tsx:164	ObjectKanban → extractRecords
plugin-kanban/src/ObjectKanban.rejectedMoveRollback.test.tsx:128	ObjectKanban → extractRecords
plugin-kanban/src/ObjectKanban.requiredWhenPrompt.test.tsx:139	ObjectKanban → extractRecords

⇒ The two cards treating value differently is the correct result, not an inconsistency. Deleting
extractRecords' value arm on #6840's numbers would break five tests. The clause-② reviewer verified
all five at their exact lines and confirmed each is a value-only envelope.

2. ⭐ And the 5 is a FLOOR, not the producer universe — this is the part that would bite

The clause-② reviewer surfaced a limitation of the method that #6916's own numbers do not disclose on
their face. That count comes from a scanner whose cell is the body of a find definition. Two shapes
are invisible to any body-scanner, however carefully written:

• mockResolvedValue-argument envelopes — 2 exist in plugin-grid, disclosed but uncounted;
• helper-built envelopes, where the object is assembled outside the find body.

⛔ So this card's sweep must not treat 5 as the producer universe. A zero derived the same way would
carry the same blind spot, and this seam has more test doubles than #6840's did. If the sweep concludes
"safe to delete", the cell definition needs to be stated and the two known-invisible shapes searched for
separately, with their own controls.

3. A same-name collision worth knowing about before touching extractRecords

Also filed (in #6917): packages/core/src/data-scope/ViewDataProvider.ts:128 declares a second, private
extractRecords reading records | data | items — a different tolerance set from
@object-ui/core's exported extractRecords (records | data | value), under the same name. ⇒ A
sweep that greps the name will conflate two functions that disagree about which undeclared keys they
honour.

The reusable pin form is set

#6916 published the refusal-pin form for this family (its section 5), and #6837's first slice is adopting
it. ⛔ Do not invent a third spelling here — copy it, so all three cards' pins read alike.

---

Generated by Claude Code