A live query's preload on an on-demand collection waits for any persisting optimistic transaction
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 12/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- typescript
- 领域
- databases
调研方向
The hang comes from commitNextPendingTransactionBatch in packages/db/src/collection/state.ts, which holds accepted sync transactions while an optimistic one persists, and from whenSyncAccepted in packages/db/src/sync-receipt.ts. Start with the repro in packages/query-db-collection/tests/refetch-ordered-prefix-oracle.test.ts. Done means a focused Collection-lifecycle test where a new live query's preload settles during a held mutation, and the harness workaround is removed. The issue itself says whether this needs a design decision first.
由索引模型根据 Issue 内容生成。
描述
Summary
While an optimistic transaction persists on an on-demand Query Collection, a new live query on that Collection does not become ready. Its preload() waits until the transaction settles. This happens even when the transaction touches rows the new query does not read.
Reproduction
Found while #2154 added an optimistic-hold dimension to packages/query-db-collection/tests/refetch-ordered-prefix-oracle.test.ts.
- Create an on-demand Query Collection with an
onUpdate(oronDelete) handler that waits on a promise the test controls. - Load some rows, then call
collection.update(id, ...)on one loaded row. The handler now waits. - Create a second live query on the same Collection, for example
where id = <another id>, and callpreload(). - The preload does not settle until the handler's promise resolves. Without step 2, it settles at once.
Seven variants all hang at step 3. They cover an update or a delete hold, the same row or another row, and a backend change first or not.
Why
commitNextPendingTransactionBatchholds every accepted sync transaction back while an optimistic transaction persists (packages/db/src/collection/state.ts).- Collection readiness and mutation-handler writes wait for acceptance (
whenSyncAccepted,packages/db/src/sync-receipt.ts). - A
loadSubsetload settles only when its rows are visible, so a load during the hold waits for the transaction.
Is this intended?
Probably not as a product promise: a slow mutation (offline, slow server) delays every live query that opens during it. It is the same mechanism as #2169, where held sync rows hide an optimistic removal. It may need the same law decision: which observations may wait for a persisting transaction.
Suggested witness
A focused Collection-lifecycle witness: a held mutation, then a new live query's preload must settle. Then remove the harness workaround in the query-db refetch oracle, which today defers awaiting preload() until the hold's release.
This issue was written by Isaac.
- 主要语言
- TypeScript
- 星标
- 3.9k
- 派生
- 272
- 平均合并
- 1 天 21 分钟
- 30 天内合并 PR
- 241
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
TanStack/db 的其他 Issue
-
难度 5/5 一周以上 新手友好度 8/100
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 25/100
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 5/100
维护者通常 1 天内回复
-
query-db: a Query refetch that joins a loader's refetch acquisition does not report shifted pages未关闭
难度 5/5 一周以上 新手友好度 8/100
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 18/100
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 76/100
melgarafael/DeskcommCRM#3000 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
callstackincubator/simlock#639 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 80/100
aws/agentcore-cli#2606 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 7 天内回复
-
ai-driven-qa bug Cosmetic
难度 2/5 1-3 小时 新手友好度 74/100
维护者通常 1 天内回复