finding(plugin-list): ObjectGallery issues the same unbounded fetch objectui#7210 just capped on the four non-grid views — no `$top`, and no ceiling reaches it

[os-project-manager]

Measured while implementing objectui#7210's ruling a′ (the platform row ceiling on gantt / calendar / map / tree). Filed unassigned, and deliberately not fixed in that PR — see the scope note at the bottom.

Measured

packages/plugin-list/src/ObjectGallery.tsx, the standalone fetch path:

const results = await dataSource.find(schema.objectName, {
 $filter: schema.filter,
 ...(expand.length ? { $expand: expand } : {}),
});

No $top. That is the same shape objectui#7210 filed against the gantt and that ruling a′ has now bounded on four views: with no cap in the request, the adapter returns the entire filtered result set, and nothing an author writes can bound it — pagination.pageSize cannot cap a query that never carried a cap.

Control that this is a real reading and not a stale grep: the four views the ruling names all carried the identical shape and now carry $top: NON_GRID_ROW_CEILING_TOP; object-kanban ($top: schema.limit ?? DEFAULT_KANBAN_LIMIT) and object-timeline ($top: schema.limit ?? DEFAULT_TIMELINE_LIMIT) are the two neighbours that already cap, so the absence here is a property of this file rather than of the sweep.

Why it is filed separately rather than folded in

The ruling's scope is the non-grid visualisations, named explicitly: "gantt, and by the same rule calendar, map, tree". The argument it rests on is that those four cannot be paged without lying — a gantt's range, a map's camera fit and a tree's parent pointers are all computed over the whole set.

A gallery is not in that family. It is a card grid: it is page-shaped, it renders under ListView's paging chrome, and the honest fix for it is plausibly paging, not a platform ceiling. Applying #7210's constant here would have been the lane inventing a fifth member of a ruled set, so it was left alone.

⚠️ Which of the two it should get is a real question and not obviously the same answer as #7210's, which is the reason this is a card rather than a line in that PR:

• paging — consistent with the chrome already above it, and ListView already knows how to page. But ObjectGallery's own fetch runs only when the gallery owns its data, so this needs checking against which host is in play.
• the A gantt lens fetches its rows twice — once paged (which feeds the footer) and once unbounded (which feeds the chart), so the footer misdescribes the chart and the real fetch has no ceiling #7210 ceiling — one constant, already built, already footnoted. Cheap, and strictly better than nothing, but it would extend a ruled scope by inference.

Severity, stated rather than asserted

Not measured in a browser, and no application impact is claimed. The hazard is the one #7210's body sets out and is inherited unchanged: invisible at a few hundred rows, the whole table into the browser on a large object, with no knob reachable from view metadata. Unlike the four capped views the gallery has no footnote either, so a large result set here is still both unbounded and silent.

Related: objectui#7210 (the ruling and the four capped views) · objectui#7189 (plugin-grid's page-scoped grouping, the neighbouring "what is this surface actually describing" defect).