Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#2,085 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
playwright, sqlite, typescript
Ambito
backend, database

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
TypeScript
Stelle
3.9k
Fork
272
Merge medio
1g 1h
PR unite (30g)
210

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di TanStack/db

Tutte le issue di TanStack/db

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.