Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Persisted multi-tab: order source transactions by server position

Abierto
  • ¿Algo no está bien?
#2,209 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
database, distributed-systems

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
3.9k
Forks
277
Merge medio
17 h 54 min
PR fusionados (30 d)
226

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de TanStack/db

Todos los issues de TanStack/db

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.