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

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

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

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

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
javascript, sqlite, typescript
領域
backend, database

調査の方向性

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.

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

説明

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.

主要言語
TypeScript
スター
729
フォーク
96
平均マージ
2日 5時間
マージ済み PR（30日）
24

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

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

powersync-ja/powersync-js のほかの issue

powersync-ja/powersync-js の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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