Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

A second live query over a refetched on-demand source keeps a short joined window

オープン
  • 何か問題がありますか？
#2,155 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
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 JOIN markers on the row's join key (link), WHERE the marker exists, ORDER BY rank ASC with an index on rank.
  • Collection A has limit 2. Collection B (the second live-query Collection) has limit 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:

  1. The backend inserts row 10, with rank 1 and no marker. The provider does not send it yet.
  2. Row 0 changes its join key, so it no longer matches a marker. The provider does not send this yet.
  3. 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 3 passes.
  • 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.fails replay, 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
平均マージ
22時間 54分
マージ済み PR（30日）
236

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

TanStack/db のほかの issue

TanStack/db の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。