DEFAULT_SQLITE_BUSY_TIMEOUT_MS

const DEFAULT_SQLITE_BUSY_TIMEOUT_MS: 1000 = 1_000

Defined in: src/persistence/Constants.ts:62

Busy timeout applied to every SQLite handle this package opens, in milliseconds.

Setting one at all is a portability fix rather than a tuning knob (#124). The drivers disagree on their built-in default — measured: bun:sqlite 0, node:sqlite 0, better-sqlite3 5000 — so with no explicit pragma the same store code fails a contended write instantly on Bun and Deno and blocks for five seconds on Node. Identical behaviour across Bun, Node and Deno is a project-wide promise, and this broke it silently.

The value is deliberately far below better-sqlite3’s 5000. SqliteDriver is synchronous, so the busy handler blocks the whole event loop for the duration of the wait — nothing else in the process runs, cluster heartbeats included. defaultFailureDetectorOptions declares a peer unreachable after 2000 ms and down after 5000 ms, so inheriting 5000 would let a single contended write stall a node long enough for its own cluster to evict it. 1000 ms caps the worst case at half the unreachable threshold and is still three orders of magnitude more than a local commit needs.

busyTimeoutMs: 0 opts out and restores fail-fast SQLITE_BUSY.

Lives here rather than beside one options type because it backs the busyTimeoutMs field of both SqliteJournalOptions and SqliteSnapshotStoreOptions, and applies to any handle the package opens — including one built directly through buildSqliteDatabase.