@lunora/db 1.0.0-alpha.8 → 1.0.0-alpha.81

package/dist/packem_shared/collection-options.d-BA8jp3ji.d.mts

@@ -0,0 +1,357 @@
+import { OutboxSink, LunoraClient, FunctionReference, SubscriptionError } from '@lunora/client';
+import { CollectionConfig } from '@tanstack/db';
+import { OnlineDetector } from '@tanstack/offline-transactions';
+/**
+ * Reserved `mutationFns` key the unified outbox routes raw `client.mutation`
+ * offline writes through. `defineCollections` registers a handler under this
+ * name that reads `transaction.metadata` (functionPath + args) and replays the
+ * write, so a db app's direct mutations ride the same durable executor as its
+ * collection inserts instead of the standalone {@link OutboxSink} fallback.
+ */
+declare const OUTBOX_MUTATION_FN_NAME = "__lunora_outbox__";
+/**
+ * Provenance stamped on a durable write at enqueue time: the two questions a
+ * replay cannot answer from the persisted row once the write outlives the
+ * session that made it — WHO queued it, and WHICH shard it belongs to.
+ *
+ * Shared so both replay paths (`db.actions.*` and the reserved
+ * `__lunora_outbox__` handler) check the same fields; they drifted apart once
+ * already, and only one of them had the identity guard.
+ */
+interface WriteProvenance extends Record<string, unknown> {
+  /** Issuing identity fingerprint; a replay drops the write when it no longer matches. */
+  identity: string | null;
+  /** Captured, not re-read at replay: a queued write follows the shard it was made against even if the app reboots pointed at another. */
+  shardKey?: string;
+}
+/** The metadata an outbox-routed transaction carries so its replay can call `client.mutation`. */
+interface OutboxMutationMetadata extends WriteProvenance {
+  args: Record<string, unknown>;
+  clientId: string;
+  functionPath: string;
+  /** Stable `${clientId}:${mutationId}` replay key; passed back as the mutation id so a committed-but-unacked replay is server-idempotent. */
+  idempotencyKey: string;
+  mutationId: number;
+}
+/** A committable outbox transaction handle (the `OfflineTransaction` the executor mints). */
+interface OutboxTransaction {
+  commit?: () => Promise<unknown>;
+  mutate: (callback: () => void) => unknown;
+}
+/**
+ * The slice of the TanStack `OfflineExecutor` the {@link createExecutorOutboxSink}
+ * drives. Declared structurally so `@lunora/db`'s outbox glue doesn't widen its
+ * coupling to the executor's full surface (and stays unit-testable with a fake).
+ */
+interface OutboxExecutor {
+  createOfflineTransaction: (options: {
+    autoCommit?: boolean;
+    idempotencyKey?: string;
+    metadata?: Record<string, unknown>;
+    mutationFnName: string;
+  }) => OutboxTransaction;
+  getPendingCount: () => number;
+}
+/** Tuning for {@link createExecutorOutboxSink}. */
+interface ExecutorOutboxSinkOptions {
+  /** Max persisted-but-unconfirmed writes before `enqueue` rejects with `OFFLINE_QUEUE_OVERFLOW` (default 1000, matching `OfflineQueue`). */
+  maxItems?: number;
+  /** `mutationFns` key the replay handler is registered under (default {@link OUTBOX_MUTATION_FN_NAME}). */
+  mutationFnName?: string;
+}
+/**
+ * The blessed {@link OutboxSink} over the TanStack `OfflineExecutor` — the single
+ * durable write path for a `@lunora/db` app. It persists each offline write as an
+ * executor transaction carrying the `client.mutation` target in `metadata`, then
+ * ports the two semantics the executor lacks vs the built-in `OfflineQueue`.
+ *
+ * First: a `maxItems` cap that **rejects** a new write at capacity with an
+ * `OFFLINE_QUEUE_OVERFLOW`-coded error — the {@link OutboxSink} contract, matching
+ * `OfflineQueue`. Rejecting (rather than evicting the oldest) preserves the
+ * at-least-once promise: an already-persisted write is never silently dropped, and
+ * the caller surfaces back-pressure to the issuing mutation (which rolls its
+ * optimistic write back).
+ * Second: the identity guard lives in the replay handler (`defineCollections`), which drops a write whose captured `identity` no longer matches — see {@link OutboxMutationMetadata}.
+ */
+declare const createExecutorOutboxSink: (executor: OutboxExecutor, options?: ExecutorOutboxSinkOptions) => OutboxSink;
+/** A row carrying the Lunora document id. */
+type Row = Record<string, unknown> & {
+  _id: string;
+};
+/** The subset of a TanStack DB sync write channel that {@link makeDiffEmit} drives. */
+interface SyncWriter<T extends object> {
+  begin: () => void;
+  commit: () => void;
+  write: (message: {
+    type: "insert" | "update";
+    value: T;
+  } | {
+    key: string;
+    type: "delete";
+  }) => void;
+}
+/** Index a row list into a keyed map. */
+declare const toMap: <T extends object>(rows: ReadonlyArray<T>, getKey: (row: T) => string) => Map<string, T>;
+/**
+ * Build an `emit(next)` that diffs a desired keyed snapshot into a collection's
+ * sync channel — only changed rows are written, so a reconnect snapshot or a
+ * scope change never churns the synced view out from under a pending optimistic
+ * row. The last-synced base is tracked in `syncedJson`.
+ *
+ * Change detection compares rows by `JSON.stringify`, which is key-order
+ * sensitive — safe here because server snapshots have stable column order
+ * across reconnects (same query projection). A sync source with unstable key
+ * ordering would need a structural compare instead.
+ *
+ * `syncedJson` holds the JSON-serialized form of each last-synced row, keyed
+ * by row id. It is the **sole** synced-state map — no parallel row-object map
+ * is kept. Each incoming value is serialized exactly once per tick (for both
+ * comparison and cache update), so the previous value is never re-serialized.
+ *
+ * Lifecycle: `syncedJson` must be owned by the caller at the same scope as any
+ * other per-collection state (e.g. outside the `sync.sync` callback), so the
+ * cache persists correctly across sync restarts. A new `makeDiffEmit` closure
+ * created on restart receives the same map reference and starts from the
+ * committed synced state — no spurious diffs on reconnect.
+ */
+declare const makeDiffEmit: <T extends object>(syncedJson: Map<string, string>, writer: SyncWriter<T>) => (next: Map<string, T>) => void;
+/**
+ * Run a Lunora mutation under the outbox's retry policy.
+ *
+ * The retryable/permanent split keys on whether the failure carries a server
+ * application error `code` (set by `@lunora/client`'s rpc when the server returns
+ * a `{ error: { code, … } }` envelope — validation, conflict, etc.). A coded
+ * error is a definite verdict: surface it as a `NonRetriableError` so the executor
+ * stops and TanStack DB rolls the optimistic insert back. Everything without a
+ * code is transient — a `fetch` network failure (`TypeError`) or an HTTP/infra
+ * blip the rpc surfaces as a code-less `Error` (a 5xx gateway page, a non-JSON
+ * body) — so it's rethrown as-is and the durable outbox replays it. Keying on
+ * `error instanceof TypeError` alone would wrongly drop the latter.
+ */
+declare const runOutboxMutation: (mutate: () => Promise<unknown>) => Promise<void>;
+/**
+ * An "always attempt" online detector. We deliberately don't trust
+ * `navigator.onLine`: some environments (and Playwright's `setOffline` under
+ * Firefox) leave it stuck, which would freeze the outbox. Instead the executor
+ * always tries the send and {@link runOutboxMutation}'s transient-error retry
+ * handles real offline; the periodic tick nudges the executor to drain the outbox
+ * so a queued write replays promptly once connectivity returns.
+ *
+ * `isOnline` is therefore intentionally always `true` — it gates the executor's
+ * attempts, not a UI signal. A consumer that wants to show real connectivity
+ * should read `navigator.onLine` itself, separately from this detector.
+ */
+declare const createOptimisticOnlineDetector: () => OnlineDetector;
+/** A watermark pair — the two monotonic lines a checkpoint registry gates on. */
+interface CheckpointWatermark {
+  /** Op-log cursor the server has durably applied. */
+  checkpoint?: number;
+  /** Highest `clientSeq` the server has echoed back for this client. */
+  mutationId?: number;
+}
+/** Reported when the fallback releases an overlay the sync stream never confirmed. */
+interface CheckpointFallbackEvent {
+  /** Which gate released. */
+  kind: "checkpoint" | "mutationId";
+  /** How long the release waited past the server acknowledgement, in ms. */
+  waitedMs: number;
+  /** The watermark that was acknowledged but never confirmed by a sync frame. */
+  watermark: number;
+}
+/** Counters for {@link CheckpointRegistry.stats} — feeds a debug/diagnostics surface. */
+interface CheckpointRegistryStats {
+  /** How many times the fallback timer released an overlay (a non-zero value means sync frames are being lost). */
+  fallbacks: number;
+  /** Overlays currently waiting on a checkpoint cursor. */
+  pendingCheckpointWaiters: number;
+  /** Overlays currently waiting on a mutation id. */
+  pendingMutationWaiters: number;
+}
+/** Tuning for {@link createCheckpointRegistry}. */
+interface CheckpointRegistryOptions {
+  /**
+   * How long an {@link CheckpointRegistry.acknowledge}d watermark waits for the
+   * authoritative sync frame before the overlay is released anyway. Default 3000.
+   * `0` disables the fallback (an overlay then waits forever for the frame — the
+   * pre-fallback behavior, which hangs on a dropped poke).
+   */
+  fallbackMs?: number;
+  /**
+   * Notified each time the fallback fires. A fallback is never *correct* — it
+   * means a poke or `settled` frame that should have confirmed the write never
+   * arrived — so this is the hook for a warning or a metric. Defaults to a
+   * one-shot `console.warn`.
+   */
+  onFallback?: (event: CheckpointFallbackEvent) => void;
+}
+/**
+ * Resolves the TanStack optimistic-overlay drop against the server's confirmed
+ * watermarks. A mutator's optimistic transaction returns `awaitMutationId(id)`
+ * (or `awaitCheckpoint(cursor)`); TanStack keeps the overlay until that promise
+ * settles, so the row de-duplicates exactly as the synced server value lands — no
+ * flash of the optimistic row disappearing then reappearing.
+ *
+ * Two inputs, deliberately distinct:
+ *
+ * - {@link CheckpointRegistry.resolve} is the **authoritative** advance, called by whoever owns
+ * the watermark stream — a `data`/`delta` frame's `lastMutationId`, or a shape poke's
+ * `checkpoint`. The synced rows have landed, so gates open immediately.
+ * - {@link CheckpointRegistry.acknowledge} is the **provisional** advance, called when the server
+ * has accepted the write (the mutator RPC ack) but the matching rows have not
+ * necessarily been delivered yet. Releasing here would drop the overlay before
+ * the synced row exists — a visible flicker — so instead it arms a bounded
+ * fallback. If the authoritative frame lands first the fallback is cancelled;
+ * if it never lands, the overlay is released after `fallbackMs` and the event is
+ * reported rather than hanging forever.
+ *
+ * That pairing is why a lost poke degrades to a late overlay drop instead of a
+ * permanently stuck `isPersisted` promise.
+ */
+interface CheckpointRegistry {
+  /**
+   * Record a server-accepted watermark whose rows may not have synced yet: arms
+   * the bounded fallback described on {@link CheckpointRegistry}. Safe to call
+   * repeatedly; a watermark already passed is a no-op.
+   */
+  acknowledge: (watermark: CheckpointWatermark) => void;
+  /** Resolve once the server has acknowledged the op-log `cursor`. */
+  awaitCheckpoint: (cursor: number) => Promise<void>;
+  /** Resolve once the server has echoed a `lastMutationId >= id` for this client. */
+  awaitMutationId: (id: number) => Promise<void>;
+  /**
+   * Tear the registry down: `clearTimeout` every armed fallback timer and empty
+   * the armed set. Idempotent. A discarded registry (Vite HMR dispose, sign-out)
+   * can otherwise hold up to `fallbackMs` of pending `setTimeout`s alive through
+   * their closures — keeping a Node/SSR event loop from draining. Distinct from
+   * {@link CheckpointRegistry.resolve}: `resolve` settles parked *waiters* (and disarms the timers it
+   * subsumes as a side effect); `dispose` guarantees no armed timer survives,
+   * independent of any watermark.
+   */
+  dispose: () => void;
+  /** Advance the gates from a sync frame's watermark; later callers past the mark settle immediately. */
+  resolve: (watermark: CheckpointWatermark) => void;
+  /** Diagnostics counters — notably how often the fallback had to fire. */
+  stats: () => CheckpointRegistryStats;
+}
+/** Default fallback window: long enough that a slow-but-arriving poke wins, short enough that a UI isn't visibly stuck. */
+declare const CHECKPOINT_FALLBACK_MS = 3e3;
+/**
+ * A standalone checkpoint/mutation-id registry. Prefer {@link getShardCheckpoints}
+ * unless you are wiring a bespoke watermark stream — a registry must be shared by
+ * every collection on a shard (see that function for why).
+ */
+declare const createCheckpointRegistry: (options?: CheckpointRegistryOptions) => CheckpointRegistry;
+/**
+ * Release every pending overlay gate for `client` and drop its shard registries.
+ *
+ * The hot-reload / teardown escape hatch. When a module that owns collections and
+ * mutators is replaced — a Vite HMR update, a sign-out that rebuilds the data layer
+ * — the *old* bindings may still have transactions parked in `awaitMutationId`. The
+ * subscriptions that would have resolved them are gone with the old module, so
+ * without this those promises never settle and every one of their
+ * `transaction.isPersisted` waiters hangs forever.
+ *
+ * Resolving to `Infinity` settles the parked waiters (the writes were already sent;
+ * the server is authoritative regardless), and dropping the registries means the
+ * replacement module's bindings start from a clean per-shard gate.
+ *
+ * ```ts
+ * // In the module that owns the data layer:
+ * import.meta.hot?.dispose(() => releaseShardCheckpoints(client));
+ * ```
+ */
+declare const releaseShardCheckpoints: (client: LunoraClient) => void;
+/**
+ * The shared checkpoint registry for `client` + `shardKey` — created on first use.
+ * This is the registry {@link lunoraCollectionOptions} and
+ * {@link import("./define-mutators").bindMutators} default to, which is what makes
+ * a multi-collection shard work without the caller relaying pokes between
+ * registries by hand.
+ *
+ * `options` applies **only when the registry is created**. Because the point is that
+ * every collection and mutator on a shard shares one gate, a later call cannot
+ * retune an existing registry — it returns the existing one and `options` is ignored.
+ * To control `fallbackMs` / `onFallback`, build the registry yourself with
+ * {@link createCheckpointRegistry} and pass it explicitly to every
+ * `lunoraCollectionOptions` and `bindMutators` call for that shard.
+ */
+declare const getShardCheckpoints: (client: LunoraClient, shardKey?: string, options?: CheckpointRegistryOptions) => CheckpointRegistry;
+/**
+ * A replication-shape sync source (the local-first partial-replication path).
+ * Mutually exclusive with {@link LunoraCollectionConfig.list}: the collection
+ * live-syncs the named shape's rowset via the client's poke protocol
+ * (`subscribeShape`) instead of a full-table `list` query subscription.
+ */
+interface ShapeSource {
+  /** Validated shape parameters (the partition selector — e.g. `{ channelId }`). */
+  args?: Record<string, unknown>;
+  /** The `defineShape` export name registered in `LUNORA_SHAPES`. */
+  name: string;
+  /** Routes the subscription to a specific shard's DO when the table is sharded. */
+  shardKey?: string;
+}
+/** Declarative inputs for {@link lunoraCollectionOptions}. */
+interface LunoraCollectionConfig<TRow extends Row> {
+  /**
+   * The registry optimistic overlays are gated on. Defaults to the shared
+   * per-shard registry ({@link getShardCheckpoints}), which is what a
+   * multi-collection shard needs — pass one explicitly only to isolate a
+   * collection's gate (tests) or to supply custom {@link CheckpointRegistryOptions}.
+   */
+  checkpoints?: CheckpointRegistry;
+  /** The Lunora client to subscribe through. */
+  client: LunoraClient;
+  /** Row key extractor — defaults to `row._id`. */
+  getKey?: (row: TRow) => string;
+  /** Collection id (TanStack identity) — defaults to the `list` function path (or `shape:` + the shape name). */
+  id?: string;
+  /** The Lunora query that lists the rows (the full-table sync source). Mutually exclusive with {@link LunoraCollectionConfig.shape}. */
+  list?: FunctionReference;
+  /**
+   * When the collection starts syncing. `"lazy"` (default) starts on the first
+   * `useLiveQuery` subscriber; `"eager"` starts at creation (TanStack's
+   * `startSync`) — for small "instant" reference data you want warm at boot.
+   * No effect on a `scopeBy` collection, which has nothing to sync until scoped.
+   * (Even eager, TanStack pauses sync while there are no subscribers, per its
+   * `gcTime` lifecycle — "warm while referenced", not pinned forever.)
+   */
+  load?: "eager" | "lazy";
+  /** Notified when the underlying subscription errors; the collection always leaves `loading` regardless. */
+  onError?: (error: SubscriptionError) => void;
+  /** When set, the collection stays empty until {@link LunoraCollectionOptions.scope} points it at args (sharded). */
+  scopeBy?: string;
+  /** A replication shape as the sync source (partial replication). Mutually exclusive with {@link LunoraCollectionConfig.list}. */
+  shape?: ShapeSource;
+  /**
+   * Routes the `list` subscription — and the confirmed-mutation watermark its
+   * data/`settled` frames advance the checkpoint gate from — to a specific
+   * shard's DO. Applies to the `list` source; a `shape` carries its own
+   * {@link ShapeSource.shardKey}. Without it the list path falls back to the
+   * default ("") watermark bucket, which must not be compared against a
+   * per-shard mutator's sequence line (it would drop a sharded overlay early or
+   * hang it forever).
+   */
+  shardKey?: string;
+}
+/** The result of {@link lunoraCollectionOptions}: a TanStack collection config plus its sync controls. */
+interface LunoraCollectionOptions<TRow extends Row> {
+  /** Resolves optimistic-overlay drops against the server's confirmed watermarks. */
+  checkpoints: CheckpointRegistry;
+  /** Pass to TanStack's `createCollection`. */
+  config: CollectionConfig<TRow, string>;
+  /** Re-point a `scopeBy` collection's subscription (omit `args` to detach). No-op for unscoped collections. */
+  scope: (args?: Record<string, unknown>) => void;
+}
+/**
+ * Build a TanStack DB collection config (+ sync controls) that live-syncs a
+ * Lunora `list` query through the client. This is the reusable core lifted out of
+ * {@link import("./define-collections").defineCollections}: the same `makeDiffEmit`
+ * diff-into-channel, `autoIndex:"eager"` + B-tree indexes, scoped-resubscribe, and
+ * fail-safe `markReady`-on-error behavior, exposed as a standalone
+ * collection-options creator so apps (and codegen) can compose it directly.
+ *
+ * The returned `checkpoints` registry lets a mutator runtime resolve optimistic
+ * overlays against confirmed server watermarks (see {@link CheckpointRegistry}).
+ */
+declare const lunoraCollectionOptions: <TRow extends Row>(options: LunoraCollectionConfig<TRow>) => LunoraCollectionOptions<TRow>;
+export { CHECKPOINT_FALLBACK_MS as C, ExecutorOutboxSinkOptions as E, LunoraCollectionConfig as L, OUTBOX_MUTATION_FN_NAME as O, Row as R, SyncWriter as S, CheckpointFallbackEvent as a, CheckpointRegistry as b, CheckpointRegistryOptions as c, CheckpointRegistryStats as d, CheckpointWatermark as e, LunoraCollectionOptions as f, OutboxExecutor as g, OutboxMutationMetadata as h, createCheckpointRegistry as i, createExecutorOutboxSink as j, createOptimisticOnlineDetector as k, getShardCheckpoints as l, lunoraCollectionOptions as m, makeDiffEmit as n, runOutboxMutation as o, releaseShardCheckpoints as r, toMap as t };