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

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

Ouverte
  • Quelque chose ne va pas ?
#2,085 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é
4/5
Temps estimé
3-5 jours
Accessibilité débutants
45/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
playwright, sqlite, typescript
Domaine
backend, database

Piste de recherche

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.

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

Description

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.
Langage dominant
TypeScript
Étoiles
3.9k
Forks
268
Merge moyen
1 j 2 h
PR mergées (30 j)
206

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.