bench: pretable renders no rows after the row-model migration (#321) — scroll control is dead

[blove]

Summary

The pretable adapter renders no rows in the bench. scroll reports partial with rendered_rows_peak: 0 at every scale, and pretable's own scroll benchmark — the control the comparative runsets are measured against — produces no numbers at all.

Bisected to #321.

Bisect

S2, pretable, scroll, dev scale, one repeat each:

commit	status	rendered_rows_peak	scroll_frame_p95_ms
4bd57b3f (72e7d47d~1)	completed	12	16.7
72e7d47d — feat: complete incremental row-model migration (#321)	partial	0	—
94a44d58 (#324)	partial	0	—
ef59816e (#325)	partial	0	—
8461c8d0 (current main)	partial	0	—

Reproduce:

pnpm bench:matrix --adapters=pretable --scripts=scroll --scenarios=S2 --scale=dev --repeats=1

Confirmed at smoke, dev and hypothesis — all three partial, all rendered_rows_peak: 0.

Symptom detail

From the run summary:

scroll viewport unavailable for pretable in current runtime
internal telemetry rendered rows: 0
internal telemetry loaded rows: 3000
internal telemetry planned height: 0
internal telemetry viewport range: 0-0

The model loads its rows (3000) but the surface projects none: planned height 0, viewport range 0-0. So this is the row-model → surface projection, not data loading.

Relationship to #327

Same commit, and plausibly the same seam. #327 is the group script producing 0 group rows; this is the scroll path producing 0 rows of any kind. A probe against the library directly (setQuery({ rowGroups }) on PretableSurface) does produce group rows, and packages/react tests pass, so the library's own path works — which points at how the bench's externally-owned model (createBenchRowModelOwner + model.setQuery) attaches to the surface after the migration.

One inconsistency worth chasing rather than assuming away: the interaction scripts on the same adapter do render rows (rendered_rows_peak 12 at smoke, 7 at dev) while scroll renders none. Whatever the fix is, it has to explain that difference.

Why it wasn't caught

bench:matrix, bench:e2e and bench:budgets are not referenced by any workflow in .github/workflows/, so nothing in CI exercises this. scroll fails loudly as partial when run by hand; group fails silently as completed (#327, fixed by #326).

Impact

Blocks the comparative re-baseline outright: pretable is the control in that runset, and a control that renders nothing cannot carry the comparators beside it. It also means the last recorded pretable scroll figure (17.7 ms p95, 2026-08-11) is the last one that exists.

No evidence of user-facing impact — the library's own grouping and rendering tests pass and the deployed site is unaffected — but that should be confirmed rather than assumed, since the bench is the only place this surfaced.

[blove]

Root cause: the harness samples before the grid mounts. The page was never broken.

I had this backwards in the issue body. The Playwright trace from a failing initial run contains the fully rendered grid:

role="grid" data-pretable-hydrated="true" data-pretable-scroll-viewport=""
aria-rowcount="121"  style="height: 320px; overflow: auto; ..."
  DIV data-pretable-scroll-content style="height: 6734px; ..."
    DIV data-pretable-row data-pretable-row-id="S2-row-0" data-pretable-row-height="136" ...

Loading the same URL by hand against pnpm preview:bench confirms it: 7 rendered rows, viewport present, scrollHeight 6755, --pretable-row-height 48px. So the surface renders, hydrates and virtualizes correctly. What fails is the measurement's ability to find it in time.

The two sampling points

waitForScrollViewport (apps/bench/src/bench-runtime.ts:1595) gives the viewport element 12 frames to appear:

async function waitForScrollViewport(root, selector, maxFrames = 12) {

When that expires the run reports scroll viewport unavailable for pretable in current runtime with rendered_rows_peak: 0 — which is exactly the scroll failure. The initial path samples the row count with no wait at all, which is why it reports completed over an empty grid rather than failing.

The fix already exists in this file, wired into only one path:

/** Waits for the initial virtual window instead of sampling a transient zero. */
export async function waitForRenderedRowBaseline(root, rowSelector, maxFrames = 120)

bench-runtime.ts:1214 uses it — inside measureBenchUpdatesRun, and nowhere else. Someone hit this in the streaming path and fixed it locally. scroll and initial still sample the transient zero, against a 12-frame budget for the viewport and none for the rows.

Why #321 is the bisect point

The incremental row model moved the first projection later than the 12-frame budget, turning what had been an occasional flake into a deterministic miss. That also explains the asymmetry noted above: the interaction scripts sequence their own settle (waitForQuietSurface, and the app settles the surface before opening the window) so they sample after the grid exists, which is why group/sort/filter-* render rows while scroll/initial do not.

Consequences worth separating

• scroll fails loudly (partial), so no bad number was recorded.
• initial fails silently: it reports completed with rendered_rows_peak: 0 and still publishes mount_ms and first_stable_viewport_ms. Those are mount timings for a grid that had not rendered a row. Any committed initial numbers taken after feat: complete incremental row-model migration #321 measure an empty shell.

Suggested fix

Give the two mount-time paths the wait the streaming path already has: raise waitForScrollViewport's budget and gate the initial sample on waitForRenderedRowBaseline before reading peaks. Then make initial refuse to report completed at zero rendered rows — the same shape as #326 for the interaction path, since silent-zero is the same failure mode as silent-unfiltered.

This also means #327 needs re-checking against a corrected harness before assuming grouping itself is broken: group rows after grouping: 0 was read at the same kind of sampling point.