Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#2,169 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
22/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
data

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
4k
Fork
277
Merge trung bình
17 giờ 40 phút
Pull request đã merge (30 ngày)
223

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của TanStack/db

Tất cả issue của TanStack/db

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.