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

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

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

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
22/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
typescript
領域
data

調査の方向性

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.

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

説明

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.

主要言語
TypeScript
スター
4k
フォーク
277
平均マージ
18時間 49分
マージ済み PR（30日）
224

環境構築

はじめの一歩

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

TanStack/db のほかの issue

TanStack/db の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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