Filed by the domain:ui execution seat (session session_012wwHa4aaFybxXrfmfHioDM). Surfaced during objectui#7179's implementation by a malformed-block test the lane wrote, which it then narrowed to exclude null rather than ride the fix — correctly, since this is a different defect class from that card's silent wrong answer.
Filed unassigned.
The claim
A null entry inside grouping.fields[] crashes the entire grid. ObjectGrid's groupValueFormatter memo dereferences the entry's field property with no null guard, throwing a TypeError before any projection is built.
Confirmed PRE-EXISTING, not introduced by #7179: the lane checked the identical code at that branch's base commit 4f596e01a, where only the line number differs.
Why it is a different class from objectui#7179
#7179 is a silent wrong answer — one group labelled (empty) holding every row, no error, nothing on screen indicating a problem. This is the opposite failure mode: a loud total crash, and loud is the better half of that pair. A thrown TypeError is findable; the (empty) bucket is what cost a downstream repo a browser session to disprove.
That is also the argument for its lower priority. It fails safe in the sense that matters: nobody ships a view believing it works.
How reachable is it
That question is the card, and it is not yet answered. GroupingFieldSchema.field is a bare string and the block is authored JSON, so the reachable paths are worth enumerating before choosing a fix:
- a hand-authored
grouping.fields: [null], or a trailing comma in a source that permits it; - a generated or agent-written view block — this repo's premise is that agents write compact JSON, so a null from a generator is not exotic;
- a runtime mutation from the grouping toolbar popover, if it can ever produce a hole.
If author-time validation already rejects a null entry, this is unreachable in practice and the fix is a cheap defensive guard. If it does not, the crash is a live authoring hazard and the schema should refuse it. Measure which before fixing — the answer decides whether this is a guard or a validation gap.
Already partly pinned
The harvester added by objectui#7179, collectGroupingFieldRefs in @object-ui/core, handles null correctly, and that behaviour is pinned in packages/core/src/utils/__tests__/grouping-fields.test.ts — a unit file that needs no grid to mount.
So the shared reader is already safe. What remains unguarded is ObjectGrid's own groupValueFormatter memo, which reads the raw block rather than going through the harvester. Routing it through the harvester may be the whole fix; that is a suggestion, not a ruling.
Provenance
The lane's reading, relayed by the PM. I have not independently reproduced the crash. Filed as a finding to verify — the first task is a failing test that mounts a grid with a null grouping entry.
Related: objectui#7179 (where this surfaced; its collectGroupingFieldRefs handles null and is the candidate fix route).
Filed by the
domain:uiexecution seat (sessionsession_012wwHa4aaFybxXrfmfHioDM). Surfaced during objectui#7179's implementation by a malformed-block test the lane wrote, which it then narrowed to exclude null rather than ride the fix — correctly, since this is a different defect class from that card's silent wrong answer.Filed unassigned.
The claim
A
nullentry insidegrouping.fields[]crashes the entire grid.ObjectGrid'sgroupValueFormattermemo dereferences the entry'sfieldproperty with no null guard, throwing aTypeErrorbefore any projection is built.Confirmed PRE-EXISTING, not introduced by #7179: the lane checked the identical code at that branch's base commit
4f596e01a, where only the line number differs.Why it is a different class from objectui#7179
#7179 is a silent wrong answer — one group labelled
(empty)holding every row, no error, nothing on screen indicating a problem. This is the opposite failure mode: a loud total crash, and loud is the better half of that pair. A thrown TypeError is findable; the(empty)bucket is what cost a downstream repo a browser session to disprove.That is also the argument for its lower priority. It fails safe in the sense that matters: nobody ships a view believing it works.
How reachable is it
That question is the card, and it is not yet answered.
GroupingFieldSchema.fieldis a bare string and the block is authored JSON, so the reachable paths are worth enumerating before choosing a fix:grouping.fields: [null], or a trailing comma in a source that permits it;If author-time validation already rejects a null entry, this is unreachable in practice and the fix is a cheap defensive guard. If it does not, the crash is a live authoring hazard and the schema should refuse it. Measure which before fixing — the answer decides whether this is a guard or a validation gap.
Already partly pinned
The harvester added by objectui#7179,
collectGroupingFieldRefsin@object-ui/core, handles null correctly, and that behaviour is pinned inpackages/core/src/utils/__tests__/grouping-fields.test.ts— a unit file that needs no grid to mount.So the shared reader is already safe. What remains unguarded is
ObjectGrid's owngroupValueFormattermemo, which reads the raw block rather than going through the harvester. Routing it through the harvester may be the whole fix; that is a suggestion, not a ruling.Provenance
The lane's reading, relayed by the PM. I have not independently reproduced the crash. Filed as a finding to verify — the first task is a failing test that mounts a grid with a null grouping entry.
Related: objectui#7179 (where this surfaced; its
collectGroupingFieldRefshandles null and is the candidate fix route).