Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Persisted multi-tab: order source transactions by server position

Đang mở
  • Có gì không ổn?
#2,209 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
database, distributed-systems

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
3.9k
Fork
277
Merge trung bình
18 giờ 12 phút
Pull request đã merge (30 ngày)
229

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của TanStack/db

Tất cả issue của TanStack/db

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.