query-db refetch oracle: a window row is missing from the source Collection after a held delete is released
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 48/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- typescript
调研方向
Start with packages/query-db-collection/tests/refetch-ordered-prefix-oracle.test.ts and run the supplied seed and path using the reproduction command. Trace the held delete, refetch, and release through the query-db code and compare the source Collection with the ordered window after release. Done means the reproduced history satisfies the coverage law, with the relevant tests passing.
由索引模型根据 Issue 内容生成。
描述
Summary
The query-db refetch oracle fails on main at bd10e564e for one random seed. The history has a held delete, two upserts, a refetch, and the release of the held delete. After it, a row sorts inside the live window, but the source Collection does not have it.
Reproduction
pnpm install
pnpm --filter @tanstack/db-ivm build
pnpm --filter @tanstack/db build
pnpm --filter @tanstack/db-sqlite-persistence-core build
cd packages/query-db-collection
TANSTACK_DB_ORACLE_SEED=-116668131 \
TANSTACK_DB_ORACLE_PATH="71:3:0:2:1:1:2:3:0:5:5:4:0:0:0:0:3:1:2:4:4:7" \
TANSTACK_DB_ORACLE_PROPERTY=query-db.refetch-ordered-prefix \
npx vitest run tests/refetch-ordered-prefix-oracle.test.ts
The random campaign of query-db.refetch-ordered-prefix found the seed. In my runs, approximately 1 of 3 random campaigns failed.
Shrunk counterexample
{
"scenario": { "encoding": "cursor", "functionKey": false, "terms": 1, "orderKey": "rank", "limit": 1, "offset": 0 },
"initial": [
{ "id": 0, "rank": 0, "marked": false },
{ "id": 1, "rank": 0, "marked": false }
],
"history": [
{ "type": "hold", "kind": "delete", "id": 1 },
{ "type": "upsert", "id": 2, "rank": 0 },
{ "type": "upsert", "id": 1, "rank": 1 },
{ "type": "refetch" },
{ "type": "release" }
]
}
Failure
coverage after release at step 4: rows [{"id":2,"rank":2,"label":"a2"}] sort at or before the window's end but are [null] in the source Collection
The coverage law applies after the release of the held write. Every row that sorts at or before the end of the served window must then be in the source Collection. Here, row 2 sorts inside the window, but the source Collection does not contain it.
Scope
- The failure also occurs with the live-query sources of #2194 and of its merge base, so it does not come from #2194.
- I did not find the cause. The shrunk history has a held delete of row 1 while row 2 is inserted, row 1 moves, and a refetch runs. That points at the refetch and the release of the held write, possibly near #2206.
This issue was written by Isaac.
- 主要语言
- TypeScript
- 星标
- 3.9k
- 派生
- 277
- 平均合并
- 17 小时 54 分钟
- 30 天内合并 PR
- 226
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
TanStack/db 的其他 Issue
-
难度 3/5 1-2 天 新手友好度 72/100
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 25/100
维护者通常 1 天内回复
-
SQLite persistence: a sync transaction whose durable write fails still changes the public Collection未关闭
难度 4/5 3-5 天 新手友好度 48/100
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
维护者通常 1 天内回复
-
sqlite-persistence: leader term write on every page load delays reading rows可能已有人在做 @KyleAMathews 今天认领。 未关闭
难度 4/5 3-5 天 新手友好度 50/100
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
kunchenguid/gh-axi#220 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 79/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
prerender: wait for env-runner worker readiness before crawling可能已有人在做 @sarankumar1325 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复