Ordered, limited live query over a string key commits `loading` first (and `orderBy().findOne()` since 0.11.1)
Maintainer thường phản hồi trong vòng 1 ngày
Một pull request liên quan đã được merge.
- #2159 của @KyleAMathews — đã merge
Đá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
- 18/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- react, typescript
Hướng nghiên cứu
The fallback is in OrderedSourceLoader.loadBoundary, and observe() decides sync versus async around isInitialFullSource and canRetryRepair in the same loader file. Run the repro test in packages/react-db/tests to see the loading-then-ready commit. Done when a string-ordered limit or findOne is ready in the first commit and the db test suite stays green, but PR #2159 already targets this and the fix needs maintainer-level understanding of the sync cut.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
- I've validated the bug against the latest version of DB packages (
@tanstack/db0.14.0,@tanstack/react-db0.5.9)
Describe the bug
An ordered, limited live query whose first orderBy term is a string commits loading with no rows on its first render, even when the source already holds every row and answers synchronously. It becomes ready one task later. The same query ordered by a number is ready in the first commit, which is what #1896 set out to guarantee.
Since 0.11.1 this also hits orderBy(...).findOne(), because #1968 made findOne() imply limit(1) (compiler/order-by.ts). On 0.11.0, orderBy(stringField).findOne() was ready in the first commit; from 0.11.1 it commits loading first. Ordering by an ISO date string and taking the latest row is a common shape, so screens that branch on "no row yet" render their empty state for a frame.
Cause
With locale string collation, canExpressCursorOrder cannot express the boundary as a cursor, so OrderedSourceLoader.loadBoundary falls back to loadFullSource(). observe() treats every full-source request as an authoritative repair. Only a full-source request made before any request has settled (isInitialFullSource) shares the initial synchronous cut, so this fallback, which is still part of the initial load, settles asynchronously.
Logged observe() decisions for the same query:
number: ordered (sync) -> boundary (sync) => ready in first commit
string: ordered (sync) -> full-source (async) => loading, then ready
To Reproduce
packages/react-db/tests (jsdom, @testing-library/react):
import { renderHook } from '@testing-library/react'
import { useLayoutEffect } from 'react'
import { createCollection, localOnlyCollectionOptions } from '@tanstack/db'
import { expect, it } from 'vitest'
import { useLiveQuery } from '../src/useLiveQuery'
it(`publishes a synchronous ordered limit over a string key in the first layout commit`, () => {
const source = createCollection(
localOnlyCollectionOptions<{ id: string; at: string }, string>({
getKey: (row) => row.id,
initialData: [
{ id: `1`, at: `2026-10-01` },
{ id: `2`, at: `2026-10-02` },
],
}),
)
const commits: Array<string> = []
renderHook(() => {
const result = useLiveQuery((q) =>
q.from({ row: source }).orderBy(({ row }) => row.at, `desc`).findOne(),
)
useLayoutEffect(() => {
commits.push(`${result.status}:${result.data?.id}`)
})
})
expect(commits[0]).toBe(`ready:2`) // receives `loading:undefined`
})
The same happens with .limit(n) instead of .findOne(), with or without an index on the field (autoIndex: 'eager', BasicIndex), and over eager sync collections as well as local-only ones. Changing at to a number makes it pass.
Expected behavior
A full-source fallback made before the live query is ready is part of the initial load, so it should share the initial synchronous cut like the first full-source request of a requiresFullSource plan.
Possible fix
canRetryRepair (the loader's "live query is ready and no window operation is active" predicate) already distinguishes the initial load:
@@ -624,9 +624,13 @@ export class OrderedSourceLoader {
const orderingInvalidationGeneration = this.orderingInvalidationGeneration
const settlesAsync = result instanceof Promise
// A requiresFullSource plan's first full-source request is its initial
- // load, not a repair, so it shares the initial synchronous cut.
+ // load, not a repair, so it shares the initial synchronous cut. So does a
+ // full-source fallback made before the query is ready, such as a boundary
+ // that a locale string order cannot express as a cursor.
const isInitialFullSource =
- isFullSource && !this.hasSettledSourceRequest && !this.needsOrderingRepair
+ isFullSource &&
+ !this.needsOrderingRepair &&
+ (!this.hasSettledSourceRequest || !this.canRetryRepair())
const canSettleSynchronously =
!settlesAsync &&
windowOperationGeneration === undefined &&
With this change at 0.14.0, the repro passes, all 383 react-db tests pass, and 12,905 of 12,906 db tests pass. The one failure, local-storage-peer-oracle.test.ts > publishes through the default same-tab Storage object, fails identically without the change.
Additional context
Related: #1894 / #1896 (same symptom for numeric keys). We are running this as a local patch on 0.14.0 in a React Native app (Expo, new architecture).
- Ngôn ngữ chính
- TypeScript
- Star
- 3.9k
- Fork
- 277
- Merge trung bình
- 22 giờ 54 phút
- Pull request đã merge (30 ngày)
- 236
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của TanStack/db
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 22/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 12/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 8/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 5/100
TanStack/db#2186 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
documentation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
components-web-app/docs#260 ·
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 65/100
521xueweihan/HelloGitHub#4025 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
ctrf-io/playwright-ctrf-json-reporter#117 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
voidzero-dev/void#478 ·
Maintainer thường phản hồi trong vòng 1 ngày