A second live query over a refetched on-demand source keeps a short joined window
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 12/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- typescript
- 领域
- data
调研方向
The payload names no source files, so start from the ordered-work oracle in #2132 and replay seed 3103989100, which is pinned as an it.fails case. Find where the second live-query Collection's ordered loader decides whether to request more rows after a refetch. The fix is done when that replay passes, the it.fails marker is removed, and the refetching-provider plus second-Collection combination can return to the random grammar.
由索引模型根据 Issue 内容生成。
描述
Problem
Two live-query Collections can read the same on-demand source. After a refetch, the second Collection can show a short ordered window. It stays short until a different change starts a load.
The ordered-work oracle in #2132 found this with a generated history. The failure also occurs with the production code on main, so #2132 does not cause it.
Minimal trace
- On-demand source with a refetching provider. The provider sends no change until a refetch, and each refetch keeps every served ordered range whole.
- Query: rows
LEFT JOINmarkers on the row's join key (link),WHEREthe marker exists,ORDER BY rank ASCwith an index onrank. - Collection A has
limit 2. Collection B (the second live-query Collection) haslimit 3. - Rows 9, 0 and 1 have rank 0 and a marker. Row 2 has rank 1 and no marker. 200 filler rows have rank 100 and up, with markers.
Steps:
- The backend inserts row 10, with rank 1 and no marker. The provider does not send it yet.
- Row 0 changes its join key, so it no longer matches a marker. The provider does not send this yet.
- The provider refetches.
Expected window of Collection B: ranks [0, 0, 100] (rows 9, 1 and the first filler row). Actual window: [0, 0]. Collection A shows the expected window.
Ingredients
The failure needs all of these:
- A refetching provider. A forwarding provider passes.
- A second live-query Collection on the same source. One Collection with
limit 3passes. - A join on the row's join key. The same history with marker changes passes.
- A tie at the window boundary with a row that the provider never sent. Without the insert of row 10, the history passes.
A source filter instead of a joined filter also passes.
Hypothesis
After the refetch, row 0 leaves both windows in one commit. Collection B must load past the rank-1 tie group, where every row fails the join. Two causes are possible:
- Collection B's ordered loader does not request again, because its last page has the same count and boundary as before.
- The rows that Collection A already loaded answer the request of Collection B.
Then nothing proves the window, and no request follows.
Evidence
- Witness trace: oracle seed 3103989100 of the ordered-work oracle in #2132. #2132 pins it as an
it.failsreplay, and excludes the refetching-provider and second-Collection combination from the random grammar until this fix.
This issue was written by Isaac.
- 主要语言
- TypeScript
- 星标
- 3.9k
- 派生
- 272
- 平均合并
- 1 天 48 分钟
- 30 天内合并 PR
- 238
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
TanStack/db 的其他 Issue
-
Ordered, limited live query over a string key commits `loading` first (and `orderBy().findOne()` since 0.11.1)可能已有人在做 @KyleAMathews 今天认领。 未关闭
难度 4/5 3-5 天 新手友好度 18/100
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 18/100
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 18/100
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 8/100
维护者通常 1 天内回复
-
难度 3/5 半天 新手友好度 58/100
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
needs triage
难度 2/5 1-3 小时 新手友好度 76/100
homarr-labs/homarr#7191 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 74/100
AvaProtocol/ava-sdk-js#276 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 75/100
apollographql/apollo-client#13493 ·
维护者通常 1 天内回复