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

Persisted Query Collection can enter error state when refetch supersedes a pending SQLite application

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

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
sqlite, typescript
領域
databases, testing-qa

調査の方向性

Start by tracing enqueueResultApplication, invalidatePendingResultApplication, and trackResultApplication through the persisted Query Collection and sync transaction code. Reproduce the interleaving with the described node:sqlite integration test, focusing on the result of commit(signal) and pending SQLite application. Done means the second refetch exposes value 3 without an application error or a stale value 1.

索引モデルが issue の本文から書いたものです。

説明

Versions
  • @tanstack/db 0.11.1
  • @tanstack/query-db-collection 1.3.2
  • @tanstack/expo-db-sqlite-persistence 0.2.26
  • @tanstack/react-db 0.5.1
Problem

A second refetch of a persisted Query Collection can leave an active collection in error when the previous query result has already committed a sync transaction but SQLite has not applied it yet. This happens during ordinary use, without cleanup or a session change.

The adapter logs:

[QueryCollection] Error applying query overlap: AbortError: Sync transaction was aborted before application
[Live Query Error] Source collection 'overlap' entered error state

The collection can retain the old row after both refetches settle.

Deterministic reproduction
  1. Create a persisted Query Collection with one row { id: 'row', value: 1 }, a QueryClient, and an Expo-SQLite-compatible database. Preload it.
  2. Decorate the database runAsync to await a deferred promise when a holdWrites flag is set. This delays SQLite application without delaying queryFn.
  3. Set holdWrites = true, change the server row to { id: 'row', value: 2 }, and call collection.utils.refetch().
  4. Wait until the query fetch is idle and its result has started applying to SQLite (the decorated runAsync has entered the wait).
  5. Change the server row to { id: 'row', value: 3 } and call collection.utils.refetch() again.
  6. Release the SQLite write; await both refetches.

Expected: value 3 is visible; no collection application error.

Actual: an AbortError is logged by trackResultApplication, and the visible row can remain value 1. The second query function did run, so this is not a fetch deduplication issue.

This also occurs when a mutation handler publishes an authoritative server row with writeUpsert while a query refresh is in flight, as in our XP award collection.

Likely cause

enqueueResultApplication calls invalidatePendingResultApplication for the previous result. That unconditionally aborts its controller. When its sync transaction has already been committed and is waiting for SQLite, aborting it removes it from the core pending queue. The newer transaction for the same row can depend on that queued transaction and gets invalidated too (SyncTransactionAbortedError).

I reproduced this in a real node:sqlite integration test. Keeping committed sync transactions alive until their SQLite application finishes, while still aborting pre-commit work, makes the test pass. A guard around cancellation after commit(signal) returns a pending application receipt is one possible fix. This is a suggested direction, not a claim that it covers all interleavings.

主要言語
TypeScript
スター
3.9k
フォーク
268
平均マージ
1日 3時間
マージ済み PR（30日）
148

環境構築

はじめの一歩

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

TanStack/db のほかの issue

TanStack/db の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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