Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Persisted multi-tab: order source transactions by server position

オープン
  • 何か問題がありますか？
#2,209 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
database, distributed-systems

調査の方向性

Read the follow-ups #2201 and #2208 and inspect the exploratory lane on oracle/two-tab-peer-histories. Start by tracing how Electric's electric:resume metadata is merged with persisted commits; the issue describes atomic { handle, offset } positions as the candidate ordering signal. Define and verify the two-tab laws against one server log with per-tab cursors, including same-tick and overlay behavior.

索引モデルが issue の本文から書いたものです。

説明

Follow-up from #2201 / #2208.

Current behavior

When several tabs open the same persisted Collection, each tab runs its own sync source and stores every source transaction it receives, through the elected leader. Durable writes are ordered by the coordinator's writer lock, not by server order. A lagging tab's copy of an older server transaction can therefore be stored and announced after a newer one has applied. Example: the log has T1 (row 1, b = 0), then T2 (row 1, b = 1). Tab A stores both. Tab B lags and stores T1 later, so storage and tab A briefly show b = 0 again. A late copy of an old truncate can briefly empty rows.

Every tab delivers the same log in order, so storage and every tab converge once the streams catch up. #2208 records this as eventual consistency between tabs. Genuinely parallel tabs are rare, so this is not urgent.

What an ordering guarantee would need

A generic, optional source position on sync commits, such as { epoch, offset }:

  • The leader drops a source write at or below the stored position for the same epoch, so durable state only moves forward.
  • A tab treats an announcement at or past the position of a transaction it committed as that transaction arriving. Its held optimistic rows release, and its own late copy is a no-op.

Findings:

  • Electric already stores electric:resume = { handle, offset } atomically with each commit. Offsets are totally ordered within a handle, and a new handle starts a new log. Today only the resume metadata is merged (by wall-clock updatedAt); rows are not ordered.
  • PowerSync does not use the persisted wrapper; its own local database coordinates tabs.
  • Persisted Query collections have no log position. They would keep today's behavior, or fall back to leader-only writes.

Leader-only writes without a position are not enough on their own: a follower still needs an identity to know when the leader's copy of its own server transaction has arrived.

Oracle

An exploratory two-tab lane is on oracle/two-tab-peer-histories. Its peer grammar gives each tab an independent source, which a real backend cannot produce. A version for this design would use one server log with a cursor per tab, and check that a tab never shows state older than the newest server position it has applied, plus the same-tick and overlay laws.

This issue was written by Isaac.

主要言語
TypeScript
スター
3.9k
フォーク
277
平均マージ
17時間 54分
マージ済み PR（30日）
226

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

TanStack/db のほかの issue

TanStack/db の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。