Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

クローズ
  • 何か問題がありますか？
#1,894 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
react, typescript
領域
databases, frontend

調査の方向性

Start at OrderedSourceLoader.observe(), especially loadSubset and the initial-load hold, then compare the eager and on-demand paths described in the issue. Run the Vitest/jsdom React probe and inspect tests covering reentrant window moves, sync write-then-throw, and cleanup during settlement. Done means synchronous eager results publish rows without loading [], while explicit window moves, repairs, and on-demand behavior retain current semantics.

索引モデルが issue の本文から書いたものです。

説明

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 (#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.

主要言語
TypeScript
スター
3.9k
フォーク
267
平均マージ
1日 13時間
マージ済み PR（30日）
78

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

TanStack/db のほかの issue

TanStack/db の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。