@rindle/daemon-client

/claim-room-epoch (RINDLE-REALTIME §2.5): bump + return the placement epoch.

The response to the ARRAY form of /migrate ({@link HttpRindleDaemonClient.migrateBatch}): a whole ordered set applied in one round-trip so a supervised daemon self-restarts ONCE for the set instead of once per migration. results are the migrations processed before any failure, in order; applied counts the newly-applied ones; schemaVersion is the latest applied id; restarting is true when the daemon is self-restarting to re-introspect (wait for it before the next call). On a failed migration error/failedId name it — the batch stops there, earlier migrations are committed (forward-only), and the daemon does NOT restart: fix forward and re-send. Unlike the single-migration form, this always arrives as HTTP 200; inspect error.

One pure migration file: either ordered DDL statements or ordered DML statements. The opaque id is the journaled idempotency key. checksum is the canonical SHA-256 content identity sent by current deploy tooling; it is required for data migrations and optional only for compatibility with legacy private DDL callers. overrideHash is an operator-reviewed checksum for the content this migration originally applied with. DDL may be additive or destructive, while RENAME and raw blob remain unsupported.

The /migrate response: applied is false when id was already journaled (an idempotent replay ran nothing); hashOverridden reports that the supplied override matched the journaled content identity; schemaVersion is the version the daemon will report AFTER it serves the new shape (the latest applied migration id, DRIZZLE-MIGRATIONS-DESIGN.md §5.3). restarting is true when the daemon is self-restarting to re-introspect (a supervised daemon with RINDLE_RESTART_ON_MIGRATE) — the caller should wait for it to come back before its next call.

One entry in a {@link MigrateBatchOutput}: the migration id, whether this apply ran it (false = the id was already journaled, an idempotent no-op), and whether its override matched the journaled content identity.

/mutate-session/begin (DAEMON-INTERACTIVE-TXN-DESIGN.md §4.1): open an interactive write transaction on the master, held open across round trips under the daemon-owned deadline. Client-attributed sessions (clientID + mid) get mid dedup/gap resolution UP FRONT — an absorbed replay opens no session and the caller must skip the mutator. statements is the accumulated write prefix to replay into the fresh transaction (sound: nothing before the first read observed DB state); query rides the begin so a one-read mutator pays exactly one extra round trip over the batch path.

A read through the open transaction (read-your-writes) — flat {sessionId, sql, params}, answered in the /execute-sql-read shape.

The SSR one-shot read (SSR-DESIGN.md §3). Materialize-or-reuse the query, read its current view ONCE, return it assembled; registers no subscriber. visibilityKey/ttlMs are optional.

The POST /query response: assembled rows (nested by name, ready to hydrate without an engine), the cvMin baseline they reflect, the per-query schema hello, and queryKey.

/room-lmids (§3.3): the domain-scoped ledger's lmid per client under doc — the room's boot probe. doc scopes the read to _rindle_room_client_mutations (§7.1), so a client's room stream never aliases its slow-path daemon stream.

One column in a {@link SchemaTable}: its name and the daemon's ColType wire name.

The daemon's introspected base-table schema (GET /schema) — the input to client-schema codegen (DRIZZLE-MIGRATIONS-DESIGN.md §6.2). Tables are sorted by name and the daemon's own bookkeeping tables (_rindle_*) are excluded.

One base table in the daemon's introspected schema: its name, ordered columns, and PK columns.

A raw read: one SELECT and its positional parameters. The read counterpart to {@link SqlTxn} — no idempotency/mutation fields (reads are idempotent).

consistency / routingKey are client-tier routing directives: consistency is consumed by {@link SplitDaemonClient }, routingKey by the read router. They ride along the wire (the router is reached through an HttpRindleDaemonClient, so routingKey must) but the daemon itself ignores them and reads only sql + params. consistency defaults to "eventual" (route to a replica, scaling reads off the write-master); set "strong" to route to the master for read-your-writes after a write to the same data. routingKey co-locates a replica read on a chosen follower (e.g. by tenant); absent, the router places it by the SQL text.

The /execute-sql-read response: result columns in order and each row as a bare cell array (NOT keyed objects — the daemon keeps per-cell object construction off the write-master; zip cols with each row client-side if you want objects). Lossless for duplicate/aliased columns.

A foreign (non-client) writer's durable identity: a stable, low-cardinality id plus that producer's own gapless sequence — the same (producer, sequence) model Kafka uses.

The daemon stores ONE row per producer and overwrites it in place, so the dedup state is bounded by how many producers you have, not by how much you write. The contract that buys: number a producer's writes 1, 2, 3, … and send them in order. seq <= last is absorbed (applied: false, nothing runs), seq == last + 1 applies, and anything beyond is a 409 gap. Express concurrency with several producer ids, not by fanning out under one — and keep ids stable and few, because a fresh id per process re-introduces unbounded growth.