v0.1.2

Fixes

• Reject duplicate primary opens while the first open is pending. A second open of the primary database arriving before the first open's #retryOpen settled used to queue another #retryOpen on the same file object; the racing retries overwrote file.accessHandle/waHandles, permanently leaking the losing handle set's runtime open-handle counts (unreclaimable, since the leaking owner is alive) and racing two WAL replays over the same shared buffers. An existing unopened primary file with retryResult === null can only mean an open in flight, so jOpen now rejects the duplicate with SQLITE_CANTOPEN before anything is allocated.

Testing

• New browser regression test drives jOpen directly through the pending window and verifies the duplicate is rejected and openHandleCount returns to 0 after closing the surviving connection.
• Published after the full verification gate: prettier check, typecheck, 21 Playwright browser tests, build.

Install

npm install memory-write-ahead-vfs@0.1.2

v0.1.1

Fixes

Owner lease claiming no longer defers recovery of dead owners' slots. claimOwnerLeaseSlot's stale-leftover reclaim never checked ownerId, so a claim scan walking past a dead owner's slot published a fresh heartbeat before its CAS lost. Every scan pushed recoverAbandonedRuntimeOwnerLeases back by a full stale window, could abort in-flight recoveries, and could wedge resetRuntime behind handles that no longer existed. Claiming now skips owned slots entirely — live, dead, or mid-recovery — so stale heartbeats keep aging into recovery.

Lease exhaustion self-heals. When every slot is taken, ensureLocalRuntimeLease now reclaims abandoned leases and retries once before throwing, so a runtime full of dead owners recovers at open time instead of failing with "owner lease capacity exhausted" until reset.

Both behaviors are covered by new browser regression tests (stale dead-owner slot left untouched; full-exhaustion recovery), each observed failing before the fix.

Verification

Published through the prepublishOnly gate: Prettier check, strict typecheck, 20 Playwright browser tests (Chromium, cross-origin isolated), build.

Install

pnpm add memory-write-ahead-vfs @journeyapps/wa-sqlite

v0.1.0

First public release of memory-write-ahead-vfs — a SharedArrayBuffer-backed in-memory write-ahead VFS for @journeyapps/wa-sqlite.

Highlights

• One shared, named in-memory SQLite runtime that structured-clones into dedicated workers — every worker runs its own SQLite WASM instance against a single copy of the database bytes.
• Segmented, growable SharedArrayBuffer storage: start small, grow in place up to the configured ceiling, no re-sharing or copying.
• Cross-worker file locks built on Atomics with heartbeat-based stale-lock recovery: dead workers' locks and lease slots are reclaimed safely (CAS-guarded claim/release/recovery protocol).
• Snapshot isolation, rollback, and checkpointing delegated to wa-sqlite's WriteAhead helper.
• Capacity limits enforced with clear errors; diagnostics expose file sizes, segment counts, lock state, and recovery counters.

Verification

Released through the prepublishOnly gate: Prettier check, strict TypeScript, 18 Playwright browser integration tests (WAL round-trips, multi-worker concurrency, dead-worker lock and lease recovery, capacity exhaustion, sequential reopen), and a clean build.

Install

pnpm add memory-write-ahead-vfs @journeyapps/wa-sqlite

Requires a cross-origin-isolated browser context with growable SharedArrayBuffer support. See the README for the worker usage example and the locking model.