Multi-tab Electric: a committed row disappears after tabs stop

Aperta
  • Qualcosa non va?
#2,283 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
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
sqlite, typescript
Ambito
database, testing

Direzione di ricerca

Start with packages/browser-db-sqlite-persistence/tests/multi-tab-electric-oracle.test.ts and replay the supplied seed and path using the documented Vitest command. Trace the reserved commit through the second tab's catch-up, tab B's stop, and tab A's final catch-up to identify when row 1 disappears; record the trace in docs/contributing/oracle-coverage.md. Done means the replay passes after the fix, fails on the parent and a hostile mutant, and preserves the committed row in durable storage and both tabs.

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

Descrizione

Summary

The multi-tab Electric oracle found a history where a durable row disappears. Two tabs share one persisted database. After a tab stops and the other tab catches up and stops, durable storage and both tabs lack row 1. The model expects row 1 with label v2.

The oracle and the behavior that it checks came in with #2265. The failure reproduces on main at 6bf0e86db. The random campaign draws a new seed for each run, so CI fails on this history only intermittently. #2263 passed CI because its run drew a different seed.

Law

A server change that a tab applied and committed stays in durable storage and in every tab after all tabs catch up. A tab stop does not remove committed rows.

Counterexample

Oracle: packages/browser-db-sqlite-persistence/tests/multi-tab-electric-oracle.test.ts, test keeps reserved commits lawful across generated multi-tab histories (random or replayed), property browser.multi-tab-reserved-history.

Counterexample: [{"tabCount":2,"steps":[
  {"kind":"server change","key":1,"pick":0},
  {"kind":"catch up","tab":0,"pick":0},
  {"kind":"server change","key":1,"pick":0},
  {"kind":"catch up","tab":0,"pick":0},
  {"kind":"catch up","tab":1,"pick":1},
  {"kind":"catch up","tab":0,"pick":0},
  {"kind":"stop","tab":1,"pick":0},
  {"kind":"catch up","tab":0,"pick":0},
  {"kind":"stop","tab":0,"pick":0}]}]

Observation after every tab caught up:

actual   {"durableRows":[{"id":2,"label":"two"}],
          "tabs":[{"tab":"A","status":"ready","rows":[{"id":2,"label":"two"}]},
                  {"tab":"B","status":"ready","rows":[{"id":2,"label":"two"}]}]}
expected {"durableRows":[{"id":1,"label":"v2"},{"id":2,"label":"two"}],
          "tabs":[{"tab":"A","status":"ready","rows":[{"id":1,"label":"v2"},{"id":2,"label":"two"}]},
                  {"tab":"B","status":"ready","rows":[{"id":1,"label":"v2"},{"id":2,"label":"two"}]}]}

Replay

Run this in packages/browser-db-sqlite-persistence:

TANSTACK_DB_ORACLE_PROPERTY=browser.multi-tab-reserved-history \
TANSTACK_DB_ORACLE_SEED=-1660880085 \
TANSTACK_DB_ORACLE_PATH="55:0:1:4:4:4:1:1:1:1:3:4:4:4:4" \
npx vitest run tests/multi-tab-electric-oracle.test.ts -t "random or replayed"

Related

  • #2281 is a different symptom from the same oracle: a deleted row returns after a peer reset and deploys. This issue is a committed row that disappears after tab stops. The two can share a cause in reserved-commit replay, so diagnose them together.
  • #2267 is a lagging resumed tab that goes into error.

Next steps

  • Diagnose which step removes row 1: the second tab's catch-up with pick: 1, the stop of tab B, or the last catch-up of tab A.
  • Record the trace in docs/contributing/oracle-coverage.md under the multi-tab Electric owner until a fix lands.
  • Fix oracle-first: keep this history as a replay, show RED on the parent, GREEN after the fix, and a hostile mutant that fails.
Lingua principale
TypeScript
Stelle
4k
Fork
277
Merge medio
1g 7h
PR unite (30g)
170

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.