Blocked-by: objectstack-ai/objectstack#17393
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:
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).
Generated by Claude Code
Blocked-by: objectstack-ai/objectstack#17393
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: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.pageSizecannot 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) andobject-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.ListViewalready knows how to page. ButObjectGallery's own fetch runs only when the gallery owns its data, so this needs checking against which host is in play.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).Generated by Claude Code