Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đã đóng
  • Có gì không ổn?
#2,029 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
30/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
sqlite, typescript
Lĩnh vực
backend, databases

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
3.9k
Fork
268
Merge trung bình
1 ngày 2 giờ
Pull request đã merge (30 ngày)
200

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của TanStack/db

Tất cả issue của TanStack/db

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.