Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Fermée
  • Quelque chose ne va pas ?
#1,894 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
react, typescript
Domaine
databases, frontend

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
TypeScript
Étoiles
3.9k
Forks
267
Merge moyen
1 j 7 h
PR mergées (30 j)
104

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de TanStack/db

Toutes les issues de TanStack/db

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.