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

Aberta
  • Algo errado?
#2,283 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
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
sqlite, typescript
Domínio
database, testing

Direção de pesquisa

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.

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

Descrição

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

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.