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

未关闭
  • 哪里不对？
#2,283 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
45/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
sqlite, typescript
领域
database, testing

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.
主要语言
TypeScript
星标
4k
派生
277
平均合并
1 天 7 小时
30 天内合并 PR
170

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

TanStack/db 的其他 Issue

查看 TanStack/db 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。