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

Aberta
  • Algo errado?
#2,085 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
45/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
playwright, sqlite, typescript
Domínio
backend, database

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.
Linguagem predominante
TypeScript
Estrelas
4k
Forks
277
Merge médio
1d 11h
PRs com merge (30d)
148

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de TanStack/db

Todas as issues de TanStack/db

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.