Skip to content
pgxsinkit

storeTargetExists

storeTargetExists(storePath, backendOverride?, env?): Promise<boolean>

Defined in: packages/client/src/store-path.ts:377

Does either backend a browser boot could own for a plain storePath ALREADY exist? The fresh-target gate for a restore (ADR-0035 decision 6) — restore refuses a target that is already there. Per backend:

  • memory (backendOverride === "memory") — a scheme-selected memory store is fresh by construction: it lives only for the instance about to be created, so there is nothing to collide with. Always false (the sanctioned test/ephemeral lane never blocks a restore).
  • file:// (Bun/Node) — filesystem existence of the datadir directory. node:fs is imported DYNAMICALLY inside this branch, never at module top level, so a browser bundle (which only ever hits the idb:// branch below) never pulls node:fs in. Relative paths resolve against the working directory, exactly as PGlite’s filesystem backend and resolveStoreDataDir do.
  • opfs:// (browser, placement probe granted) — existence of the store DIRECTORY at pgxsinkit/stores/<identity> (opfsStoreDirectoryPath), walked via navigator.storage.getDirectory() and a getDirectoryHandle chain with { create: false }. This is ONLY the fresh-target gate; it is emphatically NOT commitment authority — a store directory without a commitment marker is an uncommitted CANDIDATE, and deciding that is the store meta record’s phase machine (plan step 2), never this function. navigator.storage/getDirectory absent → best-effort false (mirrors the idb databases() stance — never fabricate a positive). A NotFoundError anywhere in the chain → false; any OTHER error propagates (a genuine failure the restore caller must see). A missing OPFS directory does not finish a granted browser check: IDB is also probed, because a predecessor or fixed-placement store may still own the same public path.
  • idb:// (browser/worker) — indexedDB.databases() enumerated for the store’s database name (storeIndexedDbDatabaseName). BEST-EFFORT: databases() is unavailable on some engines (older Firefox, certain worker contexts); when absent we CANNOT prove existence, so we report false and let the restore proceed rather than fabricate a result — a real overlay collision would still surface as a PGlite-level boot failure. We never fake a positive.

Parameters

Section titled “Parameters”

storePath

Section titled “storePath”

string

backendOverride?

Section titled “backendOverride?”

"memory"

env?

Section titled “env?”

StoreEnv = ...

Returns

Section titled “Returns”

Promise<boolean>