On-demand joined window stays short after an optimistic delete of its visible row
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 新手友好度
- 18/100
- Issue 類型
- 缺陷
- 描述清晰度
- 基本清楚
- 活躍度
- 活躍
- 技術堆疊
- typescript
- 領域
- databases
研究方向
The ordered loader and its dataNeeded leading-run count are the starting points, along with how optimistic deletes hide loaded rows from the window. Reproduce with a live query using orderBy(rank).limit(1), a left-joined filter and an on-demand source, deleting the visible row with collection.delete(key) while the handler is pending. Done when the window refills with the next eligible row, and the pinned replay and fixed-point oracle dimension pass.
由索引模型根據 Issue 內容生成。
描述
Problem
Take a live query over an on-demand source, with an ordered window and a LEFT-joined (or anti-joined) filter. It can show a short window after an optimistic delete. The window stays short until the delete persists.
Example: orderBy(rank).limit(1), a joined filter, and an on-demand source. The application deletes the visible row with collection.delete(key). The handler's promise is still pending. The window shows [], but the next eligible row exists and the provider can serve it.
The same history passes when the filter is a source predicate, and when the source is eager. It fails with joined and anti-joined filters, with and without an index.
Evidence
- The ordered-work oracle in #2132 has an optimistic-delete dimension. It is not committed yet, because the delete fails on main and on #2132. The #2132 worktree keeps the patch, and the fix PR will add it.
- Before the oracle had a fixed-point guard, one random seed (1957256835) ran for more than ten minutes. This suggests that the loader can request the hidden row again and again.
Work
- Find why the ordered loader does not refill a joined window when an optimistic delete hides a loaded row. A likely place is the leading-run count in
dataNeeded, which can count the hidden row as a proven window row. - Add the oracle dimension and a pinned replay, with a fixed-point law for repeated requests.
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 天內回覆
-
A live query's preload on an on-demand collection waits for any persisting optimistic transaction未關閉
難度 5/5 一週以上 新手友好度 12/100
維護者通常 1 天內回覆
相似的 Issue
-
streams:add
難度 2/5 1 小時以內 新手友好度 70/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 68/100
apache/rocketmq-dashboard#6872 ·
維護者通常 3 天內回覆
-
難度 2/5 1-3 小時 新手友好度 72/100
interledger/publisher-tools#931 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 62/100
ARTPARK-SAHAI-ORG/calibrate-frontend#727 ·
維護者通常 1 天內回覆
-
bug
難度 2/5 1-3 小時 新手友好度 70/100
fab-geocommuns/RNB-site#539 ·
維護者通常 2 天內回覆