Grid grouping and its per-group counts are computed over the fetched page, so a group can be missing entirely with nothing on screen saying so

[os-warren]

Blocked-by: objectstack-ai/objectstack#14556

RULED 2026-09-02 (maintainer via the director seat, batch #7, verbatim 「7189 A 其他同意」, comment 5509036555): option A — grouping on a list view is server-side. The set of groups and every number in a group header are properties of the query, not of the fetched page; rows inside a group are paged. Three halves in order: spec (objectstack#14556, domain:spec), platform (blocked on the spec half, tracked there), then this card (plugin-grid consumes server group headers, useGroupedData stops grouping the page, the grouped exclusion in useServerPagination goes, the "Partial" marker from PR #7226 is retired once counts are server-true, the "Grouping is page-scoped" docs section is rewritten). Acceptance: the 186-row, five-unit, $top: 100 fixture renders five headers reading 86/61/31/7/1 regardless of row order; every row is reachable through the UI.

Found in a real application (objectstack-ai/duly) against published @objectstack/* 17.2.0, on a grid grouped by a lookup with 186 rows across 5 distinct values. A capability gap rather than a defect in the current code — the client-side implementation is correct for what it does; nothing tells an author it is page-scoped, and the failure is silent.

Measured

A grid with grouping: { fields: [{ field: 'business_unit' }] }, default page size 100, over a store holding 186 rows distributed 86 / 61 / 31 / 7 / 1 across five units:

Business unit ▸ Northgate Operations 33
Business unit ▸ Northgate Plant 3
Business unit ▸ Northgate Quality 46
Business unit ▸ Riverside Plant 18
 ───
 100 "100 records · Showing first 100 records."

Four groups for five units. One business unit does not appear at all, and nothing on screen says a group is missing. The counts shown are page slices, not totals — the largest unit holds 86 rows in the store and its header reads 46.

Where it comes from

packages/plugin-grid/src/useGroupedData.ts groups over data, the rows already in the browser, and computes per-group aggregations from that same array:

const agg = aggregations && aggregations.length > 0
 ? computeAggregations(entry.rows, aggregations)
 : [];

So both the set of groups and every number in a group header are properties of the page, not of the query. That is a reasonable implementation of client-side grouping; the problem is that nothing distinguishes it from the server-side kind at the point where an author writes grouping: {…}.

Why it reads as data rather than as a bug

The footer does disclose "Showing first 100 records. More data may be available." But the number a reader treats as authoritative is the one in the group header, next to the group's name — and a missing group is worse than a wrong count, because a wrong number invites a second look and an absent row invites none. On a grid used as an org lens ("what is outstanding, per business unit"), a unit silently absent is a wrong answer that looks like good news.

This is the same shape as objectui#7179, filed from the same app: nothing errors, the screen is internally consistent, and the only symptom is that the answer is wrong.

Suggested direction

Server-side grouping is the durable fix, and the platform demonstrably has the capability already — the same app's dashboard groups the same field over the same data through a dataset and gets true totals. It is the grid surface that lacks it.

Short of that, two things would each remove the silent half:

1. Say it on screen. A grouped grid whose result set exceeds the page should mark the grouping as partial in the group header area, not only in the row-count footer. Even "grouped over the first 100 of 186" would prevent the wrong reading.
2. Name it at author time. grouping on a paged grid is a different feature from what its name implies. If it is going to stay client-side, the schema doc should say the groups and counts are page-scoped, so an author can decide whether that fits before shipping the view.

Application impact

Low urgency for us — we are scoping the affected lens to open work, which fits one page at this product's realistic scale and is a better lens anyway. But that is a workaround at our data size, not a fix: a deployment with more open rows than a page hits it again, silently, and we have no way to detect it from inside the app.

[os-warren]

One measurement that bounds this issue to the grid, from the same application, added here rather than as a new card because it is about #7189's scope rather than a separate defect.

We assumed the gantt lens in the same app shared this — same store, same 186 rows, groupByField: 'owner', and the same 100 records · Showing first 100 records footer under it — and filed objectstack-ai/duly#96 on that basis. Checked in a browser before acting on it, and it does not: the gantt is not page-scoped.

A gantt list view issues two fetches per load. The paged one (top=100) feeds the footer; a second, unbounded one feeds the chart, and @objectstack/rest applies no cap when limit is absent. Counted off the DOM: 186 task rows + 12 group rows = 198 × 40px = the 7920px the task list scrolls, spanning the full 2026-01-31 → 2026-12-31 range of the whole result set — six months past the 100-row page's own max(due_date). All 12 owner groups rendered, including the one whose only row falls outside the page.

So this issue stays a grid card. useGroupedData is the whole of it, and a fix here should not assume the other grouped surfaces are waiting on the same change.

Two things that may still be useful to whoever picks this up:

• The disclosure half generalises even where the grouping half does not. The footer is the paging chrome, not the visualisation's; on the gantt it described a fetch the user was not looking at. Suggestion 1 in the issue body — "say it on screen, in the group header area, not only in the row-count footer" — is the part that holds across surfaces, and for the same reason: the footer is not a statement about what was grouped.
• The gantt's own two-fetch/unbounded behaviour is filed separately as objectui#7210; it is a different defect, not a second instance of this one.

---

Generated by Claude Code

[os-warren]

Triage — finding · domain:ui · priority:p2 · needs-user-decision · queued, not dispatched

Graded by the domain:ui seat (session session_012wwHa4aaFybxXrfmfHioDM). Held for two reasons, neither of them a judgment on the card's value.

1. It is behind #7179 in the same file surface

#7179 is in flight against plugin-grid's $select projection. This card's fix lives in the same package and, depending on shape, plausibly the same components. Running both at once buys a merge conflict in exchange for nothing — the lanes would race to reshape grouping from two directions. This one goes out when #7179 lands.

There is a substantive ordering reason too, not just a mechanical one. #7179 changes what this card is measuring. Today a grouping field absent from columns collapses every row into one (empty) bucket; once the projection carries the grouping field, the groups resolve and then the page-scoping described here becomes the visible failure. Dispatching this first would mean writing group-header disclosure against numbers that are about to change underneath it.

2. The durable fix is a decision, the disclosure is not

Splitting the card the way #7210 was split:

• Server-side grouping — the card's own preferred fix, and it notes the platform already demonstrates the capability through a dataset on the same field over the same data. That is an architecture decision with an API surface, not something this seat rules. Escalated to [pm:seat] domain:ui @ objectui — 🟢 session_01EMrWaQw3XS5DxTHxp4yRyC · R1 · landed #7349 #7182 #7004 #6810 #7212, closed #7221 · ⚠️ 2 OPEN DECISIONS #7399 #7402 block #7391 + #7400 #5560.
• Suggestion 1, say it on screen — dispatchable once Grid grouping collapses every row into one "(empty)" bucket when the grouping field is not also a displayed column — select is built from columns alone #7179 lands, and it is the half that survives whichever way the decision above goes. The comment on this issue makes the stronger case for it than the body does: the footer is paging chrome, not the visualisation's, so on the gantt it described a fetch the user was not looking at (now filed as 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). A grouped grid needs its partial-ness stated where the group counts are, because that is where the reader's eye is.
• Suggestion 2, name it at author time — a docs change, no decision needed, and the cheapest of the three. Likely rides with suggestion 1.

Credit where the card earned it

The follow-up comment here is what made #7179 dispatchable this shift. It bounded the projection defect to the grid by ablating kanban, gantt and timeline in a browser — four legs, each mutation confirmed on disk and each confirmed at runtime by the changed select=. That converted "worth checking the neighbouring cases" into "the grid is the only projection-blind path of the four," which is the difference between a card an agent has to explore and one it can implement.

It also correctly refused to over-claim: sort was recorded as unmeasured rather than fine, and #7179's dispatch honours that by scoping sort out rather than treating "no failure found" as "no failure."

---

Generated by Claude Code