Ordered + limited live queries commit `loading []` even when the source answers synchronously
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- react, typescript
调研方向
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.
由索引模型根据 Issue 内容生成。
描述
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
useLiveInfiniteQueryalways addslimit, 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.
- 主要语言
- TypeScript
- 星标
- 3.9k
- 派生
- 267
- 平均合并
- 1 天 7 小时
- 30 天内合并 PR
- 104
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
TanStack/db 的其他 Issue
-
Index suggestion for collection size is gated on autoIndex, so it only fires where it is redundant未关闭
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 72/100
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 50/100
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
维护者通常 1 天内回复
相似的 Issue
-
refactor
难度 2/5 半天 新手友好度 84/100
维护者通常 5 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
OHDSI/Data2Evidence#3450 ·
维护者通常 2 天内回复
-
e2e-failure ready-to-code
难度 2/5 1-3 小时 新手友好度 90/100
redhat-developer/rhdh-plugin-export-overlays#4011 · 1 条评论 ·
维护者通常 1 天内回复
-
automation missing-model model-sync provider:ofox
难度 2/5 1-3 小时 新手友好度 72/100
anomalyco/models.dev#8421 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复