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

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 6bf0e86. 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

• Multi-tab Electric: a deleted row returns after a peer reset and deploys #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.
• Electric resume check puts a lagging tab in error when a peer deleted the row it updates #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.