[blove]

Closes #568.

The mechanism, confirmed

All three links in the issue hold, at these lines on 0af4bc36:

1. An identical row set is not an effective write. packages/row-model/src/create-local-row-model.ts:1169 (setRows) and :1247/:1251 (applyTransaction) both gate on drafted.effective — the revision is only bumped when it is, and notify: false otherwise. Turning resultMeta.total from estimate to exact at the same window changes no rows, so no revision is published.
2. Nothing else carries resultMeta to the controller. The honesty-gated windowSpacers memo (packages/react/src/pretable-surface.tsx:3827) is pushed to a mutable channel in a useInsertionEffect (:3916), and the controller reads that channel only through getWindowSpacers. setViewport short-circuits on an unchanged viewport (row-layout-controller.ts:2394), so a resultMeta-only change had no event at all.
3. The spacers are read once per plan. packages/renderer-dom/src/row-layout-controller.ts:858 — prepareWindow resolves them at the top and derives leadingHeight/trailingHeight from them, and planViewport builds totalHeight as leading + loaded + trailing.

aria-rowindex and aria-rowcount are derived from props during render (pretable-surface.tsx:3874, :7168), so they moved on the reopen render while the drawn geometry did not.

Reproduction (jsdom, gate-reopen-spacer.test.tsx)

20-row dataset, resultMeta.window.start: 10, 10 loaded rows, 44px theme row height, 800px viewport.

	gate shut (estimate)	gate reopened (exact), before the fix	correct
aria-rowcount	11	21	21
first aria-rowindex	2	12	12
first row top	0	0	440
scroll extent	440	440	880

The two announced values moved on the same tick as the prop; the two drawn values were still at the shut gate's geometry 15 seconds later, when the poll timed out.

Severity: a reachability bug, not cosmetic

The "next replan" in a real app is a scroll, a resize, or an effective row change — but the collapsed extent is what removes the first of those. In the reproduction above the extent is 440px against an 800px viewport, so there is no scroll to make: the grid announces 21 rows, draws rows 10..19 as though they were the head of the dataset, and offers the reader no gesture that would reach rows 0..9. windowGap telemetry does not rescue it either, since the "before" branch tests viewportTop < renderSnapshot.leadingHeight and that is the stale 0, so the consumer is never told to load. A grid whose loaded window fits its viewport, with a backend that returns an estimated total first and an exact one after, is stuck there for the life of the mount.

Decision: (a), a spacer-only replan

(b) required the stale window to be unreachable-by-a-user or self-healing in every realistic path, and it is neither. Chose (a).

The seam is the same one PR #522 established for setColumns: the row sequence is untouched, so the height index is reused as-is, an anchor is captured and restored, and any doubt falls back to a full replacement. refreshWindowSpacers() is that, without the clearEstimates() (nothing about the estimator changed — only the counts of rows nobody is drawing):

• The controller owns the comparison, not the caller. It records the spacer counts each publish planned with, and a call whose fresh counts match them returns before touching anything. A caller cannot make that judgment: it sees what this render computed, never what the last plan used, and those differ on every commit where a replan already absorbed the change.
• Which is what makes it free on the streaming path. Every effective setRows on a windowed grid moves trailingRows, and the replacement it triggers plans against the new counts; the refresh that follows in the same commit then finds nothing to do. Pinned by two negative tests, one of them the streaming shape exactly.
• Anchored. A 440px leading spacer appearing under rows already on screen moves the global offset to 440 + the local offset, so the reader keeps looking at the same rows instead of at blank spacer.
• A no-op when disposed, unlike setColumns/setViewport. Those carry consumer intent, so swallowing one would hide a lifecycle bug; this one is fired unconditionally from a layout effect, and an explicit-model consumer that disposes its model mid-mount commits at least once more afterwards. The full react suite found that: column-helper-date-format.test.tsx took the whole tree down on the throw.

The windowGap comment at pretable-surface.tsx that justified the non-replan is updated. Its conclusion survives — reading the plan's own geometry for the loaded-window boundary is still right — but for a sharper reason: the plan is now a commit behind for exactly one render (the layout effect that closes the gap has not run yet), and reading the plan keeps that render silent instead of reporting a gap off a pixel total nobody drew.

Tests

• packages/react/src/__tests__/gate-reopen-spacer.test.tsx — the transient end to end, at the level a user sees it.
• packages/renderer-dom/src/__tests__/window-spacer-refresh.test.ts — 5 tests: the redraw, the anchoring, and three that pin the cost (already-current, replan-absorbed, disposed).

Mutation results

mutation	outcome
remove stores.controller.refreshWindowSpacers() from the layout effect	gate-reopen-spacer fails (top stays 0px, expected 440px)
force the controller's guard to always return	gate-reopen-spacer fails identically
force the guard to never return (always republish)	both "costs nothing" tests fail
swap restoreAnchorRequest(...) for globalScroll(viewport.scrollTop)	the anchoring test fails

Every assertion in both files is killed by removing what it claims to test.

Suites

• @pretable/react: 129 files, 1779 tests, all pass.
• @pretable-internal/renderer-dom: 10 files, 173 tests, all pass.
• lint, typecheck, build, api:check, format all clean.

Bench control (the change touches the commit path)

pnpm bench:matrix --adapters=pretable --repeats=5 --scale=target --scenarios=S5 --scripts=group-updates,updates, port 4173 verified free, both sides measured in the same session on the same machine, origin/main (0af4bc36) rebuilt for the before side.

scroll_frame_p95_ms, 5 repeats each:

script	before (main)	after
group-updates	9.8, 10.1, 10.0, 10.0, 10.0 — median 10.0	10.0, 10.2, 9.7, 10.0, 10.0 — median 10.0
updates	10.1, 10.0, 10.0, 9.9, 9.9 — median 10.0	9.8, 9.7, 9.9, 10.0, 10.1 — median 9.9

long_tasks_ms 0 and frame_budget_overruns_count 0 on every run of both sides. No regression; the two distributions overlap entirely, which is what the guard predicts.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
pretable	Ignored		Sep 3, 2026 4:43pm UTC

[github-actions]

Vercel preview ready

Preview: https://pretable-qe6lgjy2k-cacheplane.vercel.app
Commit: 33d72c9f6b9d91cdd10aad26747edf74c05759e9

_{Updated automatically by the deploy-preview job.}