Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#1,990 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
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 小时
30 天内合并 PR
148

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

TanStack/db 的其他 Issue

查看 TanStack/db 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。