Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#2,085 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
playwright, sqlite, typescript
Área
backend, database

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
TypeScript
Estrellas
3.9k
Forks
272
Merge medio
1 d 45 min
PR fusionados (30 d)
208

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de TanStack/db

Todos los issues de TanStack/db

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.