Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Persisted Query Collection direct writes validate against rows older than a queued refetch

Fermée
  • Quelque chose ne va pas ?
#2,029 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
30/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
sqlite, typescript
Domaine
backend, databases

Piste de recherche

Start with packages/db-sqlite-persistence-core/src/persisted.ts and packages/query-db-collection/src/manual-sync.ts to trace when refetches are accepted and direct writes are validated. Read packages/query-db-collection/tests/ownership-lifecycle.oracle.test.ts and examine how its generators cover lock holders and direct-write kinds. Done means the oracle covers those interleavings and verifies the chosen behavior for insert, update, and delete.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Problem

In a persisted Query Collection, a Query direct write can validate against rows that are older than a refetch the source has already committed.

The persistence wrapper gives a source commit() to core only when the transaction holds the wrapper's apply lock (packages/db-sqlite-persistence-core/src/persisted.ts, applyHydrationBufferedTransaction → applyMutex.run → applyBufferedSyncTransactionUnsafe → transaction.applyToCollection()). The lock can be busy for any of these reasons:

  • A durable write is slow.
  • A mutation confirmation is in progress (persistAndConfirmCollectionMutations).
  • Startup is in progress.
  • A reload is in progress.

While the lock is busy, a committed refetch waits in the lock queue. Its result is already in the Query cache, but core has not accepted it.

A direct write (writeInsert, writeUpdate, writeDelete) validates the key against core's accepted rows when it is called (packages/query-db-collection/src/manual-sync.ts). Thus it cannot see the waiting refetch. The commit of the direct write then waits behind the refetch, so the application order stays correct. Only the validation is incorrect.

Observed

Key k exists only in the waiting refetch:

Call Persisted Query Collection Query Collection without persistence
writeInsert(k) Passes validation. The direct write wins. Throws a duplicate-key error.
writeUpdate(k) Throws UpdateOperationItemNotFoundError. k keeps the refetch value. Succeeds.
writeDelete(k) Throws DeleteOperationItemNotFoundError. k stays until the next refetch. Succeeds.

No variant enters an error state. No variant causes SQLite and the collection to disagree.

main before the settlement-drop change shows the same validation results. Also, after writeInsert(k), its Query cache does not include k.

Reachability

The window is narrow. All of these conditions are necessary:

  1. The collection has persistence.
  2. A slow storage write or a mutation confirmation overlaps a refetch.
  3. A direct write targets a key that only the waiting refetch contains.

That key is not yet visible, so code that writes only keys it shows cannot hit this.

Options
  • Accept a source commit into core at commit(), and keep only the durable write behind the lock. The accepted view then follows commit order. Mutation confirmations are also built inside the lock, so their acceptance must move to the time they reserve the lock. If it does not, an older confirmation could overwrite newer server rows. This change touches the hydration laws and reserveCommitTurn.
  • Validate a direct write when it applies, not when it is called. The direct write already waits behind the refetch, so it would validate against the correct rows. Direct-write errors would change from a synchronous throw to a rejected receipt. This is a public API change.
Test gap

The Query ownership-lifecycle oracle (packages/query-db-collection/tests/ownership-lifecycle.oracle.test.ts) does not interleave direct writes with a persisted refetch that waits on a busy apply lock. A fix should add that generator dimension for each kind of direct write and each holder of the lock.

Langage dominant
TypeScript
Étoiles
3.9k
Forks
268
Merge moyen
1 j 2 h
PR mergées (30 j)
200

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de TanStack/db

Toutes les issues de TanStack/db

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.