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

On-demand + limit: an optimistic update that moves a row out of a limited live query is not shown until the transaction settles

Ouverte
  • Quelque chose ne va pas ?
#2,169 2 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é
4/5
Temps estimé
3-5 jours
Accessibilité débutants
22/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
typescript
Domaine
data

Piste de recherche

Start from the repro script, which shows a live query with where, orderBy and limit keeping a row after an optimistic update. The payload names the path to read: CollectionSubscriber.sendChangesToPipeline, then OrderedSourceLoader.onSourceChanges and invalidateSourceOrdering, where trackOrderedLoadPromise holds publication through flushPendingChanges, and CollectionStateManager.commitNextPendingTransactionBatch, which blocks the refill write. Done means the view drops the archived row and shows the refilled gap before the transaction settles, matching eager mode and the no-limit case.

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

Description

Versions: @tanstack/db 0.15.0 + @tanstack/query-db-collection 1.4.5 (also 0.14.0 + 1.4.4)

What happens

With syncMode: "on-demand", a live query with where + orderBy + limit keeps showing a row after an optimistic update moves it out of the where. collection.get() already returns the optimistic value. The view only updates when the transaction settles, so the optimistic update is never visible in the list (e.g. archiving a message keeps it in the inbox for the whole request).

Without limit, or in eager mode, the row leaves at once. Ascending/descending order, with or without indexes, and limits at or above the row count all behave the same.

Repro

import { QueryClient } from "@tanstack/query-core";
import { parseLoadSubsetOptions, queryCollectionOptions } from "@tanstack/query-db-collection";
import { BasicIndex, createCollection, createLiveQueryCollection, createTransaction, eq } from "@tanstack/db";
const sleep = (ms) => new Promise((r) => setTimeout(r, ms));
const server = [1, 2, 3].map((n) => ({ id: n, folder: "inbox", at: n }));
const rows = createCollection(queryCollectionOptions({
  id: "rows", syncMode: "on-demand", queryClient: new QueryClient(),
  queryKey: (o) => (o?.where ? ["rows", JSON.stringify(parseLoadSubsetOptions(o))] : ["rows"]),
  queryFn: async ({ meta }) => {
    const { filters, limit } = parseLoadSubsetOptions(meta.loadSubsetOptions);
    return server.filter((r) => filters.every((f) => r[f.field[0]] === f.value))
      .sort((a, b) => b.at - a.at).slice(0, limit).map((r) => ({ ...r }));
  },
  getKey: (r) => r.id, autoIndex: "eager", defaultIndexType: BasicIndex,
}));
const view = createLiveQueryCollection((q) => q.from({ r: rows })
  .where(({ r }) => eq(r.folder, "inbox")).orderBy(({ r }) => r.at, "desc").limit(2));
await view.preload();
const show = (t) => console.log(t, view.toArray.map((r) => r.id), "row 3:", rows.get(3)?.folder, "row 1:", rows.get(1)?.folder);
show("before"); // [3, 2]
const tx = createTransaction({ mutationFn: async () => {
  await sleep(500); server[2].folder = "archive"; await rows.utils.refetch();
} });
tx.mutate(() => rows.update(3, (d) => { d.folder = "archive"; }));
await sleep(100); show("optimistic"); // expected [2, 1], got [3, 2]
await tx.isPersisted.promise; await sleep(10); show("persisted"); // [2, 1]
process.exit(0);

Output:

before [ 3, 2 ] row 3: inbox
optimistic [ 3, 2 ] row 3: archive   <- expected [ 2, 1 ]
persisted [ 2, 1 ]

Cause, as far as we traced it

The delete reaches the pipeline (CollectionSubscriber.sendChangesToPipeline). OrderedSourceLoader.onSourceChanges → invalidateSourceOrdering starts an ordered refill that holds publication (trackOrderedLoadPromise; flushPendingChanges returns early while pendingOrderedLoads.size > 0). The refill's sync write waits behind the persisting transaction in CollectionStateManager.commitNextPendingTransactionBatch, so the repair cannot settle until the transaction does.

Related: #2131 (keep the last complete snapshot during repair), #1017 and RFC #1625 (sync parked behind pending mutations). We found no issue for this exact effect.

Expected: the view drops the row at once, as it does in eager mode or without a limit, and fills the gap when the refill lands.

Langage dominant
TypeScript
Étoiles
4k
Forks
277
Merge moyen
1 j 2 h
PR mergées (30 j)
213

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.