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

[os-warren]

Found in a real application (objectstack-ai/duly) against published @objectstack/* 17.2.0, measured in a browser on a seeded store of 186 rows. Filed unassigned. Two related observations from one page load; they share a cause and I would rather they be judged together than split.

Distinct from objectui#7189, which is plugin-grid's useGroupedData grouping over a fetched page. This is the opposite problem on a different surface: the gantt is not page-scoped, and the paging chrome above it says otherwise.

Measured

One load of a type: 'gantt' list view (groupByField: 'owner', a two-rule is_not_null filter, sort: visible_from asc, no pagination block authored) issues both of these:

GET /api/v1/data/duly_task?populate=owner&top=100&select=id,subject,status,owner,visible_from,due_date
 &sort=visible_from&filter=[["visible_from","is_not_null"],["due_date","is_not_null"]]
 → 100 rows · total 186 · hasMore true

GET /api/v1/data/duly_task?sort=visible_from
 &filter=["and",["visible_from","isnotnull",null],["due_date","isnotnull",null]]
 → 186 rows · total 186 · hasMore false

Note they do not even agree on a filter dialect — the paged one sends the authored rule array, the unbounded one sends a compiled ["and", …] tree.

The chart draws the second one. Counted off the DOM rather than inferred: 186 gantt-task-row-<id> rows plus 12 gantt-task-row-__group__<id> rows, and the virtualised task list's scrollHeight is 7920px = 198 rows × 40px. The bars span 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) of 2026-06-30.

The footer reports the first one, in the paging chrome under the chart:

100 records · Showing first 100 records. More data may be available.

Why each half is worth something

1. The footer is wrong about the thing it sits under. It is the only paging disclosure on the screen, and a reader takes it as describing the chart. Here it warned that a complete chart might be partial. The same mechanism inverts the moment anything caps the second request: the footer would then say 100 records while the chart drew some other number, and nothing on screen would reconcile them. Either way it is not a statement about the chart.

That reading is not hypothetical — it is what happened. A card was filed in the application repo (objectstack-ai/duly#96) concluding from this footer that the gantt's timeline range and owner grouping were computed over a 100-row slice. The reasoning was sound given what the screen said; it just was not what the code does. It cost a browser session to disprove.

2. The fetch that matters has no ceiling. @objectstack/rest applies no cap when limit is absent, so the unbounded request returns the entire filtered result set. At 186 rows that is invisible. On a task object with 100k scheduled rows it is the whole table into the browser, with no page-size knob reachable from the view metadata — authoring pagination.pageSize cannot bound it, because this request never carried a top to begin with.

The two halves pull in opposite directions, which is the actual design question: whichever way it is settled, the footer and the chart should be describing the same fetch.

Suggested direction

1. Make the paging chrome describe the fetch the visualisation actually consumed — or suppress it on surfaces where it does not apply. A footer that reports a request the user is not looking at is worse than no footer.
2. Decide whether a non-grid view is allowed an unbounded fetch, and if it is, say so at author time. A gantt does need enough rows to compute a truthful range, which is a real argument against naive paging here — but "unbounded, silently" should be a decision rather than the absence of a top.
3. Not two requests. Whatever the answer to (2), the same rows are being fetched twice per load under two different filter dialects.

Related, same component, both closed: objectui#6419 and objectui#6460 are previous findings on this ObjectView non-grid fetch path.

Application impact

None today, and no workaround is in place for it — duly is scoping that lens to open work for a product reason (a schedule of finished work is not what the screen is for), which incidentally puts the result set at 33 rows and makes both requests agree. That is our data size, not a fix; nothing in an application can bound the unbounded request or correct the footer.

[os-warren]

Claimed and SPLIT — domain:ui execution seat

• session session_012wwHa4aaFybxXrfmfHioDM
• branch claude/issue-7210-gantt-paging-chrome

The card asks that the two observations be judged together, and they have been. Judged together, they do not ship together — one of the three is a decision this seat cannot make, and the other two do not depend on how it is made. That is the split, and it is the reason for it.

Dispatched now — halves 1 and 3

Half 1 (the footer misdescribes the chart) is dispatched because it is invariant to half 2. This is the card's own observation doing the work: "whichever way it is settled, the footer and the chart should be describing the same fetch." Correcting the paging chrome to describe the fetch the visualisation actually consumed is right if a ceiling is later added, right if one never is, and right today. It is not a bet on the outcome — so it does not have to wait for it.

Half 3 (the same rows fetched twice, under two different filter dialects) is dispatched conditionally, and deliberately not as "dedupe the requests." Deduping means choosing between the authored rule array and the compiled ["and", …] tree, and choosing wrong changes which rows come back — a silent wrong answer in a card that is about silent wrong answers. So the lane is instructed to measure first: does the paged request have any consumer other than the footer? If the footer is its only consumer, then correcting the footer to describe the chart's fetch leaves that request dead, and it can be removed without anyone picking a dialect. If it has other consumers, the lane reports and stops rather than guessing.

The dialect disagreement is recorded either way. Two code paths compiling the same authored filter differently is worth its own card if half 3 does not dispose of it.

⚠️ Escalated, NOT dispatched — half 2

Whether a non-grid view is allowed an unbounded fetch is a maintainer decision, and the card is right that the current state is the absence of a top rather than a decision. It is genuinely two-sided: a gantt does need enough rows to compute a truthful range, which is a real argument against naive paging — and at 100k scheduled rows it is the whole table into the browser with no knob reachable from view metadata, since pagination.pageSize cannot bound a request that never carried a top.

I am not ruling that, and the lane is instructed not to touch it. Adding a cap changes what a gantt draws for every existing deployment whose result set exceeds it — from a complete chart to a quietly truncated one. That is the more dangerous direction than the status quo, because a truncated schedule still looks like a schedule.

Carried to the escalation list on #5560.

One correction to the record

This card's own history is the strongest argument in it. objectstack-ai/duly#96 was filed concluding from this footer that the gantt's range and grouping were computed over a 100-row slice — sound reasoning, wrong answer, and it cost a browser session to disprove. That is half 1's severity measured rather than asserted: the footer did not merely fail to inform, it actively produced a false finding in a downstream repo.

---

Generated by Claude Code

[os-warren]

os-dev-report

{
 "issue": 7210,
 "status": "done",
 "branch": "claude/issue-7210-gantt-paging-chrome",
 "pr": "https://github.com/objectstack-ai/objectui/pull/7223",
 "premise_still_valid": true,
 "summary": "Half 1 shipped: ListView's record-count bar (row count + 'Showing first N records. More data may be available.' + rows-per-page selector) is now suppressed on the gantt surface alone, behind a named constant `surfaceDrawsFetchedRows` in packages/plugin-list/src/ListView.tsx. Suppression rather than re-description, because ListView cannot report the chart's count without a new upward channel from ObjectGantt whose meaning would change if a ceiling is ever added; suppression is invariant to half 2, which is the property the split was made for. HALF 3'S CONDITION FAILED and nothing was deduped: the paged request has five consumers besides the footer, two of them behavioural. HOW MANY REQUESTS: three, not two - one paged ($top: pageSize, $select, authored filter array, issued by ListView) and TWO unbounded (ObjectGantt.reload, before and after its own object-schema read settles; the second adds $expand). Neither unbounded call carries $top. IS THE CHROME SHARED: yes - one block in ListView rendered for every viewType, and it is correct everywhere but gantt, so the change is scoped to gantt and both a grid and a kanban control pin that. WHY THE GANTT IS DIFFERENT: plugin-gantt's ObjectGanttRenderer destructures { schema } and hands its child only schema and dataSource, forwarding no host props - the only view wrapper that does not (grid, kanban, calendar, map and tree all spread props). So ListView's `data` never reaches the chart and ObjectGantt queries for itself. Forwarding it would cap the chart at one page, which is exactly half 2's forbidden direction, so it was not done.",
 "tests": "All at f3d7b3cd3 (git rev-parse --short HEAD of the final commit). (1) `pnpm exec vitest run packages/plugin-list/ packages/plugin-gantt/` from the repo root: 'Test Files 113 passed (113) / Tests 1183 passed (1183)'. (2) New files: packages/plugin-list/src/__tests__/ListView.ganttPagingChrome-7210.test.tsx (4 cases: 2 gantt, 1 grid control, 1 kanban control) and packages/plugin-gantt/src/ObjectGantt.hostDataProp-7210.test.tsx (2 cases: adapter rows drawn instead of the host `data` page; no $top or $skip in any issued query). (3) REVERSE VERIFICATION, direction and counts predicted BEFORE running: removing `surfaceDrawsFetchedRows &&` from the bar's render condition turns exactly the two gantt cases red and leaves both controls green, i.e. 2 failed / 2 passed. Observed exactly that ('Tests 2 failed | 2 passed (4)'), then 'Tests 4 passed (4)' after restore. Mutation proved on disk BEFORE reading any run: removed-token count 2 to 1 and mutated-line count 0 to 1 (grep -o | wc -l, entries not lines), plus blob hash 4a1ce3c11b87efae... to 7f55c73b8e98b7b9...; the script carried a `trap restore EXIT INT TERM` with an absolute REPO_ROOT path. Restore proved by STATE, not by exit code: `git checkout HEAD -- ABSOLUTE_PATH` (never the bare form), then `git diff HEAD`, `git diff --cached` and `git status --short` all empty and the blob hash back to the HEAD blob 4a1ce3c1. (4) Typecheck: `pnpm --filter @object-ui/plugin-list run type-check` and the same for @object-ui/plugin-gantt, both exit 0 over a freshly built dependency closure (`pnpm --workspace-concurrency=2 --filter '@object-ui/plugin-list^...' --filter '@object-ui/plugin-gantt^...' build`, exit 0). Because each package's type-check is `tsc --noEmit && tsc -p tsconfig.test.json`, I proved the two NEW test files are actually inside that program with `tsc -p tsconfig.test.json --listFiles`: 1 hit each. (5) Gates, each run with output redirected before the exit code was read: check:control-bytes, check:phantom-deps, check:self-import, check:vi-mock-specifiers, check:vi-mock-inherit, check:i18n-keys, check:i18n-dead-keys, check:element-data-source-declaration, check:side-effects-array, lint:coverage ('lint coverage: 46/46 packages linted, 0 with outstanding errors'), and all four changeset guards (fixed / no-major / overwrite / presence, the last printing 'this change declares 1 changeset(s)') - every one exit 0. check:sdui-registration-pins returned exit 2 with its own 'This is exit 2, not a pass' banner (no apps/console build to weigh): recorded as NOT MEASURED, not as a colour; the diff adds no registration and moves no entry array, so it is left to CI. (6) ESLint, NARROWED and declared: 3 changed files, 0 errors, exit 0. The three pieces of evidence the narrowing needs: the population came from eslint's own flat config resolving the paths (not my guess at what counts), the file count 3 was read from `--format json` output, and eslint.config.js enables NO type-aware linting (no `project` / `projectService` under its `languageOptions`), so no untouched file's verdict can move because of this diff - which the diff also cannot do by other means, adding no config and no inline directive. (7) Control-byte self-scan over all four changed files with grep -naP: no hits. Every heavy run went through /home/user/objectstack/scripts/pm/os-verify-lock.sh with OS_VERIFY_LOCK_SLOT=objectui-7210.",
 "mcp_calls": "6 - one search_issues (dedup), two issue_write creates, one create_pull_request, one pull_request_read (body read-back), one add_issue_comment (this report). Every card and comment READ went through the zero-quota embedded-JSON web channel; repo-scoped REST is 403 for this session (probed first: GET /repos/objectstack-ai/objectui returned 403 'GitHub access is not enabled for this session'), and `gh` is absent.",
 "open_questions": [],
 "out_of_scope_findings": [
 "filed as #7221: one authored view filter reaches the wire in two dialects - ListView forwards the authored value while the gantt path recompiles it through ElementDataSourceGate's mergeFilterNodes (plugin-gantt declares `filter: true` in its mapping), which wraps two or more surviving sources as ['and', ...nodes]. Required by the ruling's item 4 (report, do not repair). Nobody has established the two shapes select the same rows; that measurement is the card's first step.",
 "filed as #7222: ObjectGanttRenderer forwards no host prop but `schema` - the only view wrapper that does not. Two certain consequences (ListView's `{...(ganttOwnsData ? {} : { data })}` clause is inert for a gantt, and the live comment above it stating that the prop 'short-circuits the renderer's own fetch' is false, which is precisely what makes #7210's double fetch invisible on a read-through) and one SUSPECTED, explicitly marked unmeasured (ListView's onRowClick / rowHeight / onRowSelect cannot arrive either, so an authored gantt `navigation` config may not be honoured - not verified in a browser). The card explicitly does NOT propose spreading props, because forwarding `data` would cap the chart at one page.",
 "NOT filed, deliberately, to avoid duplicating a card that already owns it: ObjectGantt issues TWO unbounded queries per load (the pre-schema one carries no $expand and is a wasted round trip). That is the exact 'two queries, the first unexpanded' regime already tabulated against plugin-gantt/src/ObjectGantt.tsx on #6482, which is no longer open. Re-confirmed here by measurement; recommend REOPENING #6482 rather than filing a fourth card.",
 "NOT filed, belongs to #7210's own still-open half 3: plugin-view's ObjectView non-grid path double-fetches for a gantt in the same way (its own $top: 100 query plus the chart's unbounded one). No paging chrome renders on that path, so half 1 had nothing to correct there."
 ]
}

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Halves 1 and 3 resolved — PR #7223 landed 5015fcf52. ⛔ This card STAYS OPEN for half 2.

Landing note from the domain:ui seat (session session_012wwHa4aaFybxXrfmfHioDM). Clearing pm:dispatched; keeping needs-user-decision.

Verified by content on origin/main, with a live control:

probe	on main
surfaceDrawsFetchedRows (the fix)	2
record-count-bar testid — live control	1

The control is the one that matters: the bar was conditioned, not deleted. A probe that only checked the fix landed would pass equally if the whole record-count bar had been ripped out, which is the failure mode worth guarding against on a change whose mechanism is "stop rendering something".

Half 1 — shipped

The record-count bar is suppressed on the gantt surface alone. Everywhere else it keeps reporting, because everywhere else it is telling the truth — pinned by a grid control and a kanban control in the test file, not by assertion. On the same harness (18 rows, pageSize: 6) the grid reads 18 and the kanban reads 6 while genuinely drawing 6; only the gantt read 6 while drawing 18.

Suppression rather than re-description, deliberately: re-describing would need a new upward channel from ObjectGantt whose meaning would change if a ceiling is ever added — i.e. it would bet on half 2's outcome. Suppression is invariant to it, which is the property this card was split on.

Half 3 — condition FAILED, nothing deduped, and that is the correct outcome

The dispatch made the dedupe conditional on the paged request having no consumer besides the footer. It has five, two of them behavioural: data gates the loading skeleton and the load-error panel (so it decides whether the chart mounts at all), feeds UserFilters' option counts, and backs the client-side export.

Measured, not reasoned — with the paged response delayed, the skeleton was up and the chart had 0 rows though its own unbounded response had already arrived.

So the request could not be removed, and the lane stopped rather than picking between the two filter dialects. Good: choosing wrong there would have silently changed which rows come back, on a card about silent wrong answers.

Corrections to this card's own measurements

• Three requests, not two. One paged, and two unbounded — ObjectGantt.reload fires before and after its own object-schema read settles, the second adding $expand. Neither unbounded call carries $top.
• The root cause is a prop-forwarding asymmetry. ObjectGanttRenderer forwards only schema and dataSource — the only view wrapper that does not spread host props; grid, kanban, calendar, map and tree all do. So ListView's data never reaches the chart. Worse, the live comment in ListView claims the data prop "short-circuits the renderer's own fetch" — that comment is false, and its falseness is exactly what made this double fetch invisible to anyone reading the code. Filed as finding(plugin-gantt): ObjectGanttRenderer forwards no host prop but schema — the one view wrapper that does not, so ListView's data/onRowClick never arrive and a live comment says the opposite #7222.

⚠️ Still open on this card: half 2

Whether a non-grid view may fetch unbounded remains a maintainer decision, escalated on #5560 and unanswered. Nothing in #7223 pre-empts it.

⛔ Note the tempting wrong fix is now explicitly fenced off in the code: forwarding data to the chart would cap a gantt at one page — "turning a complete schedule into a quietly truncated one that still looks like a schedule." That is half 2's forbidden direction reached by the back door, and the landed docblock says so.

Filed alongside

• finding(plugin-gantt/plugin-list): one authored view filter reaches the wire in two dialects — ListView forwards it, the gantt path recompiles it through mergeFilterNodes #7221 — one authored filter reaches the wire in two dialects (report-don't-repair, per the ruling). Nobody has established the two shapes select the same rows; that measurement is the card's first step.
• finding(plugin-gantt): ObjectGanttRenderer forwards no host prop but schema — the one view wrapper that does not, so ListView's data/onRowClick never arrive and a live comment says the opposite #7222 — the prop-forwarding asymmetry above.
• useSettledSchema was extracted and published with ONE adopter — the convergence #6482 asked for is 1 of 4, and the gantt's ungated double fetch is still live #7225 — while checking the lane's recommendation to reopen finding(ui): the schema-settled $expand gate is now four hand copies, and four more views resolve the schema without gating on it #6482, I measured that useSettledSchema was extracted and published with exactly one non-test adopter, so that convergence is 1 of 4 and the gantt's ungated double fetch is still live. Filed as a new card rather than reopening finding(ui): the schema-settled $expand gate is now four hand copies, and four more views resolve the schema without gating on it #6482, whose body is now a five-week-old snapshot of a tree that has moved.

---

Generated by Claude Code