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

openBrowserWASQLiteOPFSDatabase() never settles while a frozen tab holds the database

Geschlossen
  • Stimmt etwas nicht?
#1,883 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
45/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
sqlite, typescript, vite
Bereich
database, web-dev

Rechercherichtung

Start with openBrowserWASQLiteOPFSDatabase() and opfs-database.ts, then trace the OPFSCoopSyncVFS hand-over and Web Lock wait. Review create(), open_v2, and handleWorkerRequest for cancellation and error propagation, using the frozen-tab reproduction as the first test case. Done means callers can bound or abort the open, late completion releases the database, and relevant errors remain distinguishable.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

  • I've validated the bug against the latest version of DB packages

Describe the bug

If another tab has the database open and that tab is frozen, openBrowserWASQLiteOPFSDatabase() in a new tab never settles. The bundled OPFSCoopSyncVFS asks the current holder to hand over its access handles over a BroadcastChannel, then waits for the holder's Web Lock. A frozen tab can't answer. The open has no timeout or AbortSignal, so the caller can't give up and fall back to non-persisted sync. Anything waiting on the open, such as persisted collections reading their startup metadata, waits until the other tab thaws.

To Reproduce

A Vite app with @tanstack/[email protected] and [email protected]:

hang.html 
<!doctype html>
<meta charset="utf-8" />
<title>Frozen holder repro</title>
<pre id="log">Opening…</pre>
<script type="module" src="./hang.js"></script>
hang.js 
import { openBrowserWASQLiteOPFSDatabase } from "@tanstack/browser-db-sqlite-persistence";

// Tab A: load /hang.html and let it open the store. Freeze tab A, then load
// /hang.html in tab B. Tab B's open stays pending until tab A is thawed.
const log = document.querySelector("#log");
const started = performance.now();
const elapsed = () => `${((performance.now() - started) / 1000).toFixed(1)} s`;
const timer = setInterval(() => (log.textContent = `open pending for ${elapsed()}`), 250);
try {
  const db = await openBrowserWASQLiteOPFSDatabase({ databaseName: "repro.sqlite" });
  await db.execute("CREATE TABLE IF NOT EXISTS t (x)");
  await db.execute("INSERT INTO t VALUES (1)");
  log.textContent = `opened after ${elapsed()}`;
} catch (e) {
  log.textContent = `failed after ${elapsed()}: ${e.name}: ${e.message}`;
}
clearInterval(timer);
  1. Open /hang.html in tab A. It shows opened after 0.1 s.
  2. Freeze tab A by sending the DevTools protocol command Page.setWebLifecycleState with {"state": "frozen"} to it.
  3. Open /hang.html in tab B. It shows open pending for 15.0 s and keeps counting.
  4. Send {"state": "active"} to tab A. Tab B shows opened after 15.1 s.

main at 4c5a8de, which includes #1844, behaves the same when I build its opfs-database.ts against the 0.2.23 worker. Freezing fires freeze, not pagehide, so the new cleanup never runs.

Expected behavior

A way to bound the wait, such as an AbortSignal or timeout option on openBrowserWASQLiteOPFSDatabase(), so the caller can fall back to non-persisted sync. An abandoned open that completes later should release the database rather than keep holding it.

Desktop:

  • OS: Linux x86_64
  • Browser: Chrome, headless, driven over CDP
  • Version: 152.0.0.0

Additional context

  • I forced the freeze over CDP and haven't pinned down which real-world freezes hold the lock this way. Mobile browsers suspend background tabs, and any holder that never answers the hand-over request blocks the open the same way.
  • Our workaround races the open against a 2 s deadline, falls back to non-persisted semantics, and closes an open that lands after the deadline.
  • A related gap: errors thrown while OPFSCoopSyncVFS.create() runs still reach callers as OPFSWorkerRequestError with code: "INTERNAL" and only the message. #1844 adds the VFS cause to open_v2 failures, but create() runs outside that try, and handleWorkerRequest forwards error.message alone. Forwarding error.name too would let callers tell NoModificationAllowedError contention from other failures. The navigation failure that #1844 fixes arrived that way: Failed to execute 'removeEntry' on 'FileSystemDirectoryHandle' from the VFS's stale-directory sweep, reported upstream at rhashimoto/wa-sqlite#362.
Vorherrschende Sprache
TypeScript
Sterne
4k
Forks
277
Ø Merge
17 Std. 33 Min.
Gemergte PRs (30 T.)
227

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.