On-demand joined window stays short after an optimistic delete of its visible row
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 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日 48分
- マージ済み PR（30日）
- 238
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
TanStack/db のほかの issue
-
難易度 5/5 1週間以上 初心者へのやさしさ 12/100
メンテナーはふだん 1 日以内に返信
-
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 1週間以上 初心者へのやさしさ 18/100
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 8/100
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 半日 初心者へのやさしさ 58/100
メンテナーはふだん 1 日以内に返信
似ている issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
vercel/streamdown#673 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
docs(stream-protocol): document messageMetatadata on start/finish and the message-metadata chunkオープンfactory-active task-identify-harness-labels-done task-identify-issue-type-done
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
agilepathway/label-checker#721 ·
メンテナーはふだん 1 日以内に返信
-
CLI Empathy needs triage
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
chromaui/chromatic-cli#1524 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信