import { detectEngine } from '@happyvertical/smrt-core';
import { DatabaseInterface } from '@happyvertical/sql';
type DatabaseEngine = ReturnType<typeof detectEngine>;
/** Mark a worker key as live in this process. */
export declare function registerLiveWorker(workerKey: string): void;
/** Remove a worker key from this process's live set. */
export declare function unregisterLiveWorker(workerKey: string): void;
/** Whether a worker key is live in this process. */
export declare function isLiveWorker(workerKey: string): boolean;
/** Snapshot of every worker key live in this process. */
export declare function liveWorkerKeys(): Set<string>;
/**
 * Whether a worker is alive: live in *this* process (synchronous truth, never
 * starved), or holding a fresh database lease in some process. `null`/unknown
 * worker keys are never alive.
 */
export declare function isWorkerAlive(workerKey: string | null | undefined, freshLeaseKeys: Set<string>): boolean;
/**
 * Build a per-incarnation-unique worker key.
 *
 * Recovery treats a worker key as the unit of liveness, so the key must be
 * unique per process incarnation: a runner that crashes and restarts under the
 * same configured `id` must get a *new* key, otherwise its orphaned `running`
 * jobs would look owned by the live restart and never be recovered. We append
 * a random token to the (optional) configured id, which also keeps the
 * human-facing runner id stable for logs/events.
 */
export declare function createWorkerKey(baseId: string): string;
/**
 * The connection URL, honoring adapters that leave `db.url` empty and carry the
 * real URL on `db.config.url`. Used consistently for engine detection, the
 * in-memory check, and the URL handed to the off-loop thread so they never
 * disagree.
 */
export declare function resolveUrl(db: DatabaseInterface): string;
/**
 * Tune a SQLite connection for the off-loop liveness topology.
 *
 * The runner's main connection and the off-loop ticker's connection both touch
 * the same file. Stock libsql/SQLite opens in rollback-journal mode with no busy
 * timeout, so the instant two connections contend it returns `SQLITE_BUSY` —
 * surfacing as a flaky "Failed to execute raw query" under CI load. WAL lets
 * readers run concurrently with the single writer, and `busy_timeout` makes a
 * contended writer wait for the lock instead of failing immediately. Both are
 * idempotent and file-level (WAL persists for every connection to the file).
 *
 * Best-effort: a PRAGMA failure must never break startup — the in-process live
 * set keeps same-process recovery correct regardless. Callers gate this on a
 * SQLite engine so it is never issued to Postgres.
 */
export declare function tuneSqliteForConcurrency(db: DatabaseInterface): Promise<void>;
/** Resolve the database engine for a connection. */
export declare function resolveEngine(db: DatabaseInterface): DatabaseEngine;
/**
 * Whether a connection points at an in-memory SQLite database. In-memory
 * databases are single-process (nothing to recover cross-process) and a second
 * connection cannot see the same data, so the off-loop liveness thread is
 * skipped for them.
 */
export declare function isInMemory(db: DatabaseInterface): boolean;
/**
 * Whether the off-loop liveness thread can run against this connection.
 *
 * Requires a second independent connection to the same data: true for Postgres
 * and file-backed SQLite. In-memory SQLite cannot be reached from another
 * connection, and DuckDB is single-writer per file — both fall back to
 * main-loop lease renewal + the in-process live set.
 */
export declare function offLoopEligible(db: DatabaseInterface): boolean;
export {};
//# sourceMappingURL=worker-liveness.d.ts.map