Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Persisted multi-tab: order source transactions by server position

Offen
#2,209 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
typescript

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
TypeScript
Sterne
3.9k
Forks
277
Ø Merge
18 Std. 7 Min.
Gemergte PRs (30 T.)
228

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus TanStack/db

Alle Issues in TanStack/db

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.