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

browser-db-sqlite-persistence: closing the leader tab fail-stops follower collections with IndeterminateCommitError

Đang mở
  • Có gì không ổn?
#2,085 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ó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
45/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ệ
playwright, sqlite, typescript
Lĩnh vực
backend, database

Hướng nghiên cứu

Start by tracing BrowserCollectionCoordinator.assertMutationRouteUnchanged and sendRPC, then follow the persistence runtime paths named in the stack trace: persistAndBroadcastExternalSyncTransactionUnsafe and applyBufferedSyncTransactionUnsafe. Reproduce with two same-origin tabs sharing an OPFS database and close the leader while sync changes arrive. Done means a normal leader close no longer leaves follower collections permanently errored, or the supported reconciliation path is clearly documented.

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

Mô tả

Summary

With BrowserCollectionCoordinator, closing the leader tab often puts collections in the remaining tab into a permanent error state. The follower's in-flight rpc:applyCommittedTx for a sync-sourced transaction (an Electric change) waits for the closed leader, times out after 10 s, crosses leadership, and rejects with IndeterminateCommitError. The collection fail-stops, and the tab stops getting live rows.

Versions
  • @tanstack/db 0.12.3
  • @tanstack/db-sqlite-persistence-core 0.4.7
  • @tanstack/browser-db-sqlite-persistence 0.2.32 (OPFS, openBrowserWASQLiteOPFSDatabase)
  • @tanstack/electric-db-collection 0.5.8
  • Chromium (Playwright headless shell), two tabs in one browser context, same origin
Setup
  • One OPFS database, shared by the tabs through BrowserCollectionCoordinator({ dbName }) and createBrowserWASQLitePersistence({ database, coordinator }).
  • Seven persisted Electric collections (eager and on-demand), created with persistedCollectionOptions({ ...electricCollectionOptions(...), persistence, schemaVersion: 1 }).
Steps
  1. Open tab A. It becomes the leader for every collection.
  2. Open tab B. Wait until both tabs show live rows.
  3. Close tab A (page.close(), a normal close, not a crash).
  4. Keep inserting rows on the server, so that tab B's Electric streams deliver changes.
Observed

3 of 6 runs. About 10 s after tab A closes, tab B logs this (ids shortened):

IndeterminateCommitError: Commit outcome is indeterminate for collection "messages":
  rpc:applyCommittedTx:req crossed leadership from 65c2… (term 1) to 2f07… (term 2)
  <- Error: RPC rpc:applyCommittedTx:req timed out after 10000ms
    at BrowserCollectionCoordinator.assertMutationRouteUnchanged
    at BrowserCollectionCoordinator.sendRPC
    at async PersistedCollectionRuntime.persistAndBroadcastExternalSyncTransactionUnsafe
    at async PersistedCollectionRuntime.applyBufferedSyncTransactionUnsafe

The same error occurred for other collections in other runs, sometimes through flushQueuedHydrationTransactionsUnsafe. The collection stays in error, and every later update() on it throws. While tab A closes, it logs PersistedCollectionDurabilityError ... The page is closing its SQLite connection. In the other 3 runs, tab B took over every leader lock, and sending and receiving continued.

Expected

A normal leader-tab close should not fail-stop the other tab's collections. #1845 makes a leader change during a mutating RPC indeterminate and leaves reconciliation to the application. For a transaction that comes from the sync source, the source can deliver the same changes again from the durable resume offset. So one of these seems possible:

  1. The closing leader rejects or drains pending RPCs (for example on pagehide), so the follower does not wait 10 s for a leader that has gone.
  2. For sync-sourced transactions, the runtime reconciles by itself: it re-hydrates and resumes from the persisted offset instead of fail-stopping.
  3. If the application must reconcile, document how to do it for a sync-sourced collection. Is collection.cleanup() followed by a new collection the intended path?
Not done
  • No standalone reproduction yet. We saw this in an app, driven by Playwright. We can try to reduce it if that helps.
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)
206

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.