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

Shared sync worker keeps a background tab's database connection (`getRandomWrappedPort`), slowing writes in the visible tab until that tab closes

Đang mở
  • Có gì không ổn?
#1,130 1 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
45/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
javascript, sqlite, typescript
Lĩnh vực
backend, database

Hướng nghiên cứu

Start with packages/web/src/worker/sync/SharedSyncImplementation.ts, especially openInternalDB() and its getRandomWrappedPort() call, then trace handleClientClosed, markConnectionMayHaveChanged, and the connection-selection behavior used by getLastWrappedPort. Reproduce with two same-origin tabs using the listed shared-worker and OPFSCoopSyncVFS setup; done means the shared connection and connector calls use the in-use tab without the background-tab write contention described.

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

Mô tả

Versions: @powersync/web 2.4.1 (same in 2.0.0), @powersync/common 2.3.0, @powersync/shared-internals 1.3.0, @journeyapps/wa-sqlite 2.0.6. WASQLiteVFS.OPFSCoopSyncVFS, enableMultiTabs: true, shared sync worker (@powersync/web/bundled_worker). Chrome 153 and Safari 26 / WebKit (also reproduced with Playwright Chromium).

Steps to reproduce

  1. Open the app in tab A, db.connect(...).
  2. Open the same app in tab B (same origin), db.connect(...).
  3. Reload tab A.
  4. In any tab, run (await navigator.locks.query()).held and match the clientId of the shared-connection-<dbFilename>-… lock against each tab's own probe lock.

Expected: the shared sync worker reads and writes through the connection of the tab that is in use (visible/focused), or at least moves to a newly connected tab, as it already does for uploadCrud and fetchCredentials (getLastWrappedPort).

Actual: when A's port closes, the worker reopens its internal connection right away (handleClientClosed → triggerCrudUpload / markConnectionMayHaveChanged). At that moment B is the only port, so openInternalDB → getRandomWrappedPort() picks B. The worker then keeps B's connection for as long as B lives. In our measurements the connection stayed with the background tab after 4 of 4 reloads. Even without that timing, the pick is random among all non-closing ports.

Impact: with OPFSCoopSyncVFS every write in the visible tab now contends with a second connection hosted by another tab's dedicated worker. That tab is often a background tab and may be throttled. In our app, creating a card went from 129–138 ms (single tab) to 313–364 ms median (2.3–2.7×) until the background tab was closed.

Code: packages/web/src/worker/sync/SharedSyncImplementation.ts — openInternalDB() calls getRandomWrappedPort(). The connection is only replaced from the tab-closed listener.

Related: DatabaseClient.shareConnection() holds its shared-connection-* lock until the tab's own database closes. When the worker closes the shared connection earlier, the lock stays held: the tab can't be frozen, and the lock no longer tells who hosts the connection.

What we do locally (pnpm patch, happy to open a PR):

  • Tabs tell the worker whether they are in use (our app decides this with visibility/focus).
  • The worker opens its connection through the most recently activated tab. After the active tab's port closes, it waits a few seconds for an active tab to reconnect instead of settling on a background one.
  • The worker moves an open connection to a newly activated tab: it drains the old connection, closes it and calls markConnectionMayHaveChanged. Each shared connection gets its own releasable lock.
  • Connector calls (uploadCrud, fetchCredentials) also go to the active tab instead of the last connected one (getLastWrappedPort). Otherwise a background tab opened later runs uploadData against its own connection, which brings back the same contention: 252–298 ms vs 135–178 ms in our measurements.

A minimal repro (two tabs, no backend needed — the connection is borrowed on setParams) is available on request.

Found while building LayerPx — a local-first tree planner on PowerSync.

Ngôn ngữ chính
TypeScript
Star
729
Fork
96
Merge trung bình
2 ngày 5 giờ
Pull request đã merge (30 ngày)
24

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

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

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 powersync-ja/powersync-js

Tất cả issue của powersync-ja/powersync-js

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.