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

BrowserCollectionCoordinator: per-collection schemaVersions cause reset loops, and sync-ingested writes bypass leadership

Chiusa
  • Qualcosa non va?
#1,753 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à
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
sqlite, typescript
Ambito
databases, distributed-systems

Direzione di ricerca

Inizia tracciando createBrowserWASQLitePersistence, coordinator.setAdapter e ensureCollectionReadyInternal per verificare come vengono selezionati gli adapter e le versioni dello schema. Poi esamina sourceSyncConfig.sync, persistAndBroadcastExternalSyncTransactionUnsafe, requestEnsureRemoteSubset e wrappedOnUpdate, usando come riproduzione la probe di Chromium a due pagine segnalata. Il lavoro è completato quando la gestione dello schema per collection non causa più race di reset o inizializzazione, le scritture di sync sono coordinate, le opzioni di subset attraversano RPC in modo sicuro e le scritture accettate non falliscono esclusivamente perché i retry RPC di coordinator vanno in timeout.

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

Descrizione

Findings from an adoption attempt of BrowserCollectionCoordinator (@tanstack/browser-db-sqlite-persistence 0.2.12, @tanstack/db-sqlite-persistence-core 0.2.12, @tanstack/db 0.7.2, Electric collections). Verified empirically with two pages in one Chromium context (shared storage partition) plus source reading. Happy to share probe scripts.

1. The coordinator holds one adapter, so per-collection schemaVersions destroy each other's tables

createBrowserWASQLitePersistence creates one adapter per distinct (schemaMismatchPolicy, schemaVersion) and calls coordinator.setAdapter(...) for each — the coordinator keeps whichever was created last. The schema check runs in ensureCollectionReadyInternal, which every adapter method reaches, and ensureCollectionState fires acquireLeadership → getStreamPosition for every subscribed collection through that single adapter. With per-collection versions (we compute one per Electric shape) the wrong-version adapter touches every other collection: under sync-present-reset we observed collection_reset_epoch climb 0→5 during one run, a 9,475-row table wiped to 0, every reload re-syncing cold, and the registry's schema_version flipping between two collections' hashes.

A second failure appears even with matching versions: two adapter instances race ensureCollectionReadyInternal for the same collection on a fresh registry (UNIQUE constraint failed: collection_registry.tombstone_table_name, then no such table: t_… when the loser tries to reset a table the winner has not created yet). Leadership is never acquired for those collections.

One global schemaVersion (all adapters collapse to one instance) avoids all of this, at the cost that any schema change resets the whole database. Suggestion: key leader-side adapter access by collection — e.g. requireAdapter(collectionId) with a resolver passed to the constructor — instead of a single setAdapter slot.

2. Sync-ingested transactions bypass leadership entirely

sourceSyncConfig.sync() runs unconditionally in every tab, and externally-synced transactions go straight to disk (persistAndBroadcastExternalSyncTransactionUnsafe → adapter.applyCommittedTx) with no leadership check. N same-partition tabs therefore write the same stream to the same file concurrently, each minting its own term/seq, and the applied_tx dedupe on (collection_id, term, seq) silently returns on a hit — two tabs minting the same pair for different transactions means the second is dropped. We did not observe corruption in the probe, but the hazard is structural, and it means adopting the coordinator does not remove the need for an app-level single-writer election for sync-sourced collections.

3. requestEnsureRemoteSubset fails structuredClone on real LoadSubsetOptions

The follower→leader RPC posts LoadSubsetOptions over BroadcastChannel verbatim. Ours carry a subscription object with a callback: DataCloneError: (event) => options.onUnsubscribe(event) could not be cloned, ~70 occurrences per tab, retried forever by scheduleRemoteEnsureRetry. Follower-side subset widening never reaches the leader. Suggestion: serialize a wire-safe projection of the options.

4. (Minor) coordinator RPC failure lands in the user write path after the server accepted

wrappedOnUpdate runs the app's own mutation handler first and the coordinator RPC after; a wedged leader stalls the write ~30 s (RPC timeout × retries) and then rejects, rolling optimistic state back for a write the backend already accepted.

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.