Found while landing objectui#8769 on ObjectGantt. That card's brief fenced the repair to the gantt and directed the sibling renderers to a successor card rather than a widened PR, so this is that card. Not claimed.
The mismatch, twice
ObjectCalendar and ObjectMap each hold a hand copy of the exact branch objectui#8769 removed from the gantt: inside their reload, a provider: 'value' exit that calls setData plus setRowCeiling with truncated false and RETURNS, before the effectiveDataSource.find(...) a few dozen lines below. That find is the only site in each file that lowers schema.filter onto $filter, schema.sort onto $orderby via convertSortToQueryParams, and the objectui#7210 ceiling onto $top — re-derive both by symbol, the anchors here are deliberately symbol-only.
Consequence, identical in both: on the inline provider an authored filter reaches nothing and every authored row is drawn, an authored sort reaches nothing, and applyNonGridRowCeiling never runs.
Failure direction — the same fail-OPEN
The dropped key is the key that NARROWS, so the author is shown MORE rows than declared, with no diagnostic. Not a data-exposure boundary and please do not grade it as one: the rows are already in the authored schema. What is wrong is that the view answers a wider question than the one asked. Triage graded the gantt instance p2 on exactly that reading.
Why this is a successor rather than part of objectui#8769
objectui#8769's dispatch fenced its scope to provider: 'value' on the gantt in as many words, and named the sibling case as a card to FILE rather than to fix. The repair is also not literally transplantable: each renderer settles its own object schema, its own expand projection and its own gate, so the shape of "delete the branch and let it fall through" has to be re-measured per file rather than copy-pasted.
Adjacent, and different
- objectui#8220 — three plugin REGISTRATIONS declare neither
filter nor sort while the renderers lower both onto the query. That is about the registry mapping; this is about a renderer that never reaches the query at all on one provider.
- objectui#7333 — the OTHER short-circuit in the same family, the host
data prop one firing on an empty array.
- objectui#8513 —
ValueDataSource's object-dialect combinators, deliberately kept separate. This card needs no new combinator either: resolveDataSource already answers this provider with ValueDataSource, which implements the query keys locally.
What the gantt fix measured, and what it does not settle for these two
objectui#8769 also had to invert a standing pin that asserted an inline set is never capped and never footnoted. That case turned out to pin the short-circuit rather than objectui#7210 ruling a-prime, whose budget is measured in DOM elements per record and whose own measurement table was taken over the inline value provider. Whoever takes this card should expect the same question on ObjectCalendar and ObjectMap and should re-measure it there rather than inheriting the gantt's answer — the map auto-clusters above 100 markers and the calendar month grid draws at most four events per day cell, so the DOM cost per record is not the same number in the three views.
One more measured note worth carrying: the gantt repair routes the inline rows through the adapter's own deep copy, which changes object identity for anything comparing a drawn row against the authored array by reference, and makes an inline view's write-backs survive the reload that follows them. Both are consequences these two renderers would inherit.
Dedup
Run and controlled. Repo-scoped REST issue listing, state=all sorted by updated, four pages (400 rows), grepped locally for the calendar/map renderers crossed with inline / value / filter / sort / ceiling / short-circuit. Positive control: objectui#8769 itself is present in the pulled set, so the enumeration reached this neighbourhood rather than returning a confident empty. Only objectui#8220 came back on the crossed grep, and it is the registrations card named above, not this.
Filed by an automated developer seat working objectui#8769; generated with Claude Code.
Blocked-by: #9175
Generated by Claude Code
Found while landing objectui#8769 on
ObjectGantt. That card's brief fenced the repair to the gantt and directed the sibling renderers to a successor card rather than a widened PR, so this is that card. Not claimed.The mismatch, twice
ObjectCalendarandObjectMapeach hold a hand copy of the exact branch objectui#8769 removed from the gantt: inside their reload, aprovider: 'value'exit that callssetDataplussetRowCeilingwith truncated false and RETURNS, before theeffectiveDataSource.find(...)a few dozen lines below. Thatfindis the only site in each file that lowersschema.filteronto$filter,schema.sortonto$orderbyviaconvertSortToQueryParams, and the objectui#7210 ceiling onto$top— re-derive both by symbol, the anchors here are deliberately symbol-only.Consequence, identical in both: on the inline provider an authored
filterreaches nothing and every authored row is drawn, an authoredsortreaches nothing, andapplyNonGridRowCeilingnever runs.Failure direction — the same fail-OPEN
The dropped key is the key that NARROWS, so the author is shown MORE rows than declared, with no diagnostic. Not a data-exposure boundary and please do not grade it as one: the rows are already in the authored schema. What is wrong is that the view answers a wider question than the one asked. Triage graded the gantt instance p2 on exactly that reading.
Why this is a successor rather than part of objectui#8769
objectui#8769's dispatch fenced its scope to
provider: 'value'on the gantt in as many words, and named the sibling case as a card to FILE rather than to fix. The repair is also not literally transplantable: each renderer settles its own object schema, its own expand projection and its own gate, so the shape of "delete the branch and let it fall through" has to be re-measured per file rather than copy-pasted.Adjacent, and different
filternorsortwhile the renderers lower both onto the query. That is about the registry mapping; this is about a renderer that never reaches the query at all on one provider.dataprop one firing on an empty array.ValueDataSource's object-dialect combinators, deliberately kept separate. This card needs no new combinator either:resolveDataSourcealready answers this provider withValueDataSource, which implements the query keys locally.What the gantt fix measured, and what it does not settle for these two
objectui#8769 also had to invert a standing pin that asserted an inline set is never capped and never footnoted. That case turned out to pin the short-circuit rather than objectui#7210 ruling a-prime, whose budget is measured in DOM elements per record and whose own measurement table was taken over the inline
valueprovider. Whoever takes this card should expect the same question onObjectCalendarandObjectMapand should re-measure it there rather than inheriting the gantt's answer — the map auto-clusters above 100 markers and the calendar month grid draws at most four events per day cell, so the DOM cost per record is not the same number in the three views.One more measured note worth carrying: the gantt repair routes the inline rows through the adapter's own deep copy, which changes object identity for anything comparing a drawn row against the authored array by reference, and makes an inline view's write-backs survive the reload that follows them. Both are consequences these two renderers would inherit.
Dedup
Run and controlled. Repo-scoped REST issue listing,
state=allsorted by updated, four pages (400 rows), grepped locally for the calendar/map renderers crossed with inline / value / filter / sort / ceiling / short-circuit. Positive control: objectui#8769 itself is present in the pulled set, so the enumeration reached this neighbourhood rather than returning a confident empty. Only objectui#8220 came back on the crossed grep, and it is the registrations card named above, not this.Filed by an automated developer seat working objectui#8769; generated with Claude Code.
Blocked-by: #9175
Generated by Claude Code