Ordered + limited live queries commit `loading []` even when the source answers synchronously

[v-anton]

Ordered + limited live queries commit loading [] even when the source answers synchronously

Versions: @tanstack/db 0.9.0 → current main (introduced by #1797). 0.8.7 is fine.

Since the OrderedSourceLoader landed, any orderBy().limit() live query commits an empty loading result first, even when the source has already answered the request synchronously. The same query without limit publishes its rows in the first commit.

observe() settles every request through a promise, and the initial-load hold keeps publication back until that promise settles:

const request = settlesAsync ? result : Promise.resolve()
const tracked = request.then(complete, fail)

So a true from loadSubset (eager sync mode, or a warm query-collection cache) still costs at least one microtask before anything publishes. In React, that means the first render is loading [], and the rows arrive one to two tasks later.

Repro

Commits logged in useLayoutEffect, React 18, @tanstack/react-db 0.4.1:

Source	Query	0.8.7	0.9.x
eager localOnlyCollectionOptions, 200 rows	where / orderBy / groupBy / findOne	rows	rows
same	orderBy().limit(20)	20	0/loading → 20
queryCollectionOptions, syncMode: 'on-demand', warm cache, no fetch	where	—	67
same	orderBy().limit(20)	—	0/loading → 20

The last row is the one I'd expect people to hit: remounting a sorted, paginated list over a query collection with a hot cache shows a loading state without fetching anything. TanStack Query would hand back the cached result synchronously there, and query-db-collection's loadSubset does return true for it. The ordered loader discards that.

Probe (vitest + jsdom, @testing-library/react):

function Live({ out }) {
  const r = useLiveQuery(
    (q) => q.from({ e: events }).orderBy(({ e }) => e.n).limit(20),
    [],
  )
  useLayoutEffect(() => { out.push(`${r.data.length}/${r.status}`) })
  return null
}
// mount, remount → out: ['0/loading', '20/ready'] on every mount

Impact

• useLiveInfiniteQuery always adds limit, so every infinite list renders empty on mount and on every dependency change. On top of that, its window starts on commit (feat(db): shared live-query window controller (RFC #1623 phase 5) #1675; separate issue).
• Code that makes a decision on the first render reads it as "no rows". We had a route that redirected away from a tab whenever its list rendered empty; since 0.9 it redirected every time.

Proposed fix

A PR follows for the safe subset: when the source is eager (every request is served from rows the collection already holds, so it can neither write later nor fail), and the request is not an explicit window move or a repair, observe() settles in the same pass. On-demand sources, window moves and repairs keep the current behaviour.

The general case, any synchronously satisfied request including a warm query cache, is the one users will actually notice. I tried settling every synchronous result inline, and it breaks about 60 tests (reentrant window moves, sync write-then-throw, cleanup during settlement), so it needs someone who knows the reentrancy model better than I do. Happy to help test.