GeezerVison

Summary

• Fix every table paginating forever, which cost an extra row-page fetch on load and a wasted one before every row insert (the "New Row" spinner)
• Terminate row paging on the server's nextCursor instead of an advisory count, so a byte-cut short page can't be misread
• Collapse the per-read transaction guards into one round-trip

The bug

hooks/queries/tables.ts sends includeTotal: param === 0 as a boolean. requestJson parses the query through the contract on the client before building the URL (lib/api/client/request.ts — parseOptionalSchema runs before appendQuery), and the contract's preprocess only recognised the string 'true':

boolean true  -> false      <-- page 0 asked for no COUNT(*)
string 'true' -> true
undefined     -> true

So totalCount came back null on every table, every load. hasMoreTableRows treats a null total as "more may exist", so hasNextPage was permanently true:

• handleAppendRow drains before inserting → every New Row click issued a wasted GET /rows returning 0 rows, which sets isFetchingNextPage and renders the spinner row
• the scroll-prefetch effect fired an extra request on mount
• rowTotal was permanently null, so "select all" silently fell back to the unfiltered rowCount — wrong under a filter

This was latent from the start and became visible when #5351 (2026-07-03) removed the rows.length < pageSize guard that had been masking it. Fixed by reusing the existing booleanQueryFlagSchema primitive, which already accepts both forms.

I audited the other seven contracts using a string-only === 'true' coercion: all of them use z.string() or z.enum(['true','false']), which reject a boolean loudly rather than silently inverting it. This was the only silent instance, so nothing else changed.

Terminating on the cursor

totalCount is advisory, and since #6582 a page can legitimately be shorter than limit (byte cut). The response already carried nextCursor — non-null exactly when the drain proved an unreturned witness row — but the client discarded it. Now threaded through and preferred, with the count rules kept as a fallback for pages cached before this change. That also closes #6582's exposure: its own removed comment warned that a short page is only safe for a client terminating on nextCursor, and this grid was the pre-existing pager it described.

One round-trip for the read guards

withReadGuards issued SET LOCAL statement_timeout and SET LOCAL lock_timeout as separate awaited statements (plus a third for enable_seqscan). The driver runs prepare: false, so each was its own serial round-trip, on every page, count, and drain batch. They now go in a single set_config(...) SELECT — same transaction-local scope. set_config rather than semicolon-joined SET LOCAL because the driver uses the extended protocol, which rejects multiple commands per message. enable_seqscan is still only ever set to off, never explicitly on, so the unflagged path keeps the server default.

Not in this PR

• The SSE self-echo. The collaboration signal added in feat(realtime): shared room spine + live Files/Tables collaboration + Yjs document editing #5991 is echoed to the client that made the write, which invalidates rowsRoot and refetches every loaded page — defeating the optimistic work in useCreateTableRow/useUpdateTableRow about a second later. lib/table/events.ts documents this and names the fix. It's cleanly doable via the existing RequestContext AsyncLocalStorage with no changes to the ~49 signal call sites, but it touches shared request infrastructure for a tables-specific benefit, so it belongs in its own PR.
• firstBatchCap. The first drain batch is capped at 51 rows regardless of the requested 1000, so every page costs two transactions. The cap is load-bearing — it bounds worst-case memory at 4x the byte budget assuming max-size rows, and the DB returns every asked-for row before JS can byte-cut, so raising it to the caller's limit risks materializing ~400MB. Needs a server-side byte-bounded fetch, not a constant change.

Type of Change

• Bug fix

Testing

Unit tests for both fixes, each verified by reverting the fix and confirming the matching test goes red:

• the contract test fails with expected false to be true without the coercion fix
• the three cursor tests fail without the nextCursor branch

Not yet verified in a browser. The check that would confirm it end-to-end: on a ~10-row table, exactly one GET /rows on load (currently two), totalCount: 10 rather than null, and New Row issuing only the POST with no spinner.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

Audit follow-up

Three adversarial audits were run against this diff, one per fix. Two found real problems, fixed in the second commit.

Behavior changes worth knowing (not pure perf)

Select-all now respects the active filter. rowTotal has been permanently null for months, so selectAllTotalRef silently fell back to the table's unfiltered rowCount. Everything downstream — bulk delete's estimatedCount, run scope, the selected-count label, clipboard "complete:" — was therefore mis-scoped in a filtered view. Restoring totalCount fixes that. It is a correctness fix, not a regression, but it does change what those numbers say.

Restoring COUNT(*) costs latency on large filtered/sorted views. The count runs in parallel with the page drain, so the cost is max() not additive, but a filtered count goes through withSeqscanOff — on a 1M-row table the planner comment measures filtered count ~1.0s vs sorted page ~0.76s, so page 0 there goes roughly 0.76s → 1.0s. Accepted deliberately: the alternative is continuing to mis-scope select-all. This fix is a correctness restoration that costs latency; it is the nextCursor change that removes the wasted page fetch.

?includeTotal=yes and repeated keys now 400 on public v1 instead of silently meaning false. Kept rather than softened, because limit and offset in the same schema have always thrown on garbage — the silent swallow was the inconsistency. '1', 'TRUE', and ' true ' now parse as true (previously false). v2 is unaffected — includeTotal is not on its wire.

Bugs the audits caught in this diff

• An emptied view could pull back rows mid-delete. useDeleteTableRowsAsync relied on row-count arithmetic to suppress hasNextPage while the background job runs. Preferring the cursor bypassed that, so "select all, then deselect a few" on a partially-drained view would refetch the very rows being deleted. Fixed by pinning nextCursor: null on the emptied pages, with a test.
• A masked count could seq-scan the shared relation. hasFilter read only userClause, ignoring deleteMask — so during a running delete job the count took the non-seqscanOff plan despite JSONB predicates, bounded only by the 15s timeout. Pre-existing, but unreachable from the grid until page-0 counts came back. Now Boolean(userClause || deleteMask).
• MAX_QUERY_BATCHES and MAX_QUERY_LIMIT are exactly tight (both 1000). The drain's bound is only unreachable because the limit cut fires first; the count-based net that used to paper over it is gone now that clients terminate on the cursor. Documented as an invariant — raise both together.

Verified, not assumed

• The set_config change was run against a real PostgreSQL 17 through this repo's exact driver stack: identical GUC normalization to SET LOCAL, identical savepoint-rollback behavior, bound parameters accepted, and an invalid value aborts the transaction before the read runs — so there is no path where a read proceeds unguarded.
• All eight rows-cache mutation sites spread the original page, so nextCursor survives every optimistic update. TableRowsResponse declares it required, so a future page literal that omits it is a compile error.
• No premature-termination path found: hasMore is only ever set with a fetched-but-unreturned witness row, for keyset, offset, filtered, and byte-cut pages alike.