@voltro/database 0.48.0 → 0.49.0

package/CHANGELOG.md

@@ -39,6 +39,73 @@ _Changes staged for the next release accumulate here (rolled up from
 
 ---
 
+## [0.49.0] — 2026-08-23
+
+### ⚠ BREAKING
+
+- **@voltro/cli, @voltro/data-transfer, @voltro/database, @voltro/sql-sqlite, @voltro/voltro** — A data transfer is a series of short requests now — no single one may outlive a caller's budget.
+
+  **The rule:** *a request that carries bytes never runs a transfer; a request that starts a transfer never carries bytes.* It was broken in the worst available place. The upload was already chunked and resumable — many short requests, each abandonable — and then the FINAL chunk fell through and ran the whole import. So the longest request of the flow arrived AFTER the entire upload had succeeded, and a caller under a policy that caps a single request (a job runner that kills a client at ten minutes; a 30 s ingress ceiling) lost the most expensive thing they had already paid for. A single-request upload had the same shape without the excuse, and the export had no protocol at all: one request that read the whole database and streamed it back.
+
+  **Import.** `POST /_voltro/admin/import` accumulates and answers `202`. `POST /_voltro/admin/import/start` begins the run and answers `202 { runId }` as soon as the run's first row exists. `start` is idempotent per upload — it is a short request and therefore a retryable one, and without a claim a retry would begin a second destructive run from the same bytes. A claim whose run has ENDED is taken over rather than honoured forever, so a process that dies holding one cannot poison a bundle.
+
+  **Export.** `POST /_voltro/admin/export` answers `202 { runId }` and produces in the background; the bytes come back from `GET /_voltro/admin/export/download?runId=&offset=&length=` in ranges, resumable, with the total in a header. Object storage (`--bundle-key`) remains for a bundle you want to KEEP — it is no longer the only way to get one out, because requiring it would leave an instance without storage unable to export at all.
+
+  **The client.** `--max-request-seconds` (or `VOLTRO_MAX_REQUEST_SECONDS`) declares the budget — declared rather than probed, because the thing that kills a request is a policy on the caller's side and only they know it. `--detach` returns once the run has started and says the outcome is NOT known. Attached, the CLI polls the record and prints per-table progress; Ctrl-C then loses the watching and never the run.
+
+  **The trap, stated because it is the one way to get this wrong:** a failure used to arrive in the response (409 on drift, 409 on a refused mode, 500 otherwise). After the split the response is a `202`, so **a client deriving its exit code from the status line reports a failed import as a success.** The exit code comes from the polled record, in one shared function, and the drift check moved into `start` where it can still be a refusal that leaves no history.
+
+  **Two knobs that were constants.** `VOLTRO_IMPORT_UPLOAD_DIR` and `VOLTRO_EXPORT_ARTIFACT_DIR` move the staging areas off the default temp filesystem — which on a container is frequently a small tmpfs, so an instance simply could not accept a bundle the size a grown database produces, and the failure arrived as a write error halfway through an upload somebody had been waiting on.
+
+  **Renamed:** `voltro data imports` → `voltro data transfers`, and `_voltro_data_imports` → `_voltro_data_transfers` with a `direction` column. The command showed one direction and now shows both; the table rename carries its rows via the declarative differ on every dialect and needs nothing from you. The CLI rename ships a `manual` codemod — the command lives in scripts, CI jobs and runbooks, which `voltro update` cannot see or rewrite. The four PUBLIC exports that named the same record were renamed with it (`ImportRun`, `describeImportRun`, `IMPORT_RUNS_TABLE`, `_voltroImportRunsTable`); those are application source, they ship their own `transform` codemod, and they have their own entry.
+- **@voltro/database, @voltro/voltro** — The run-history exports say `transfer`, not `import`.
+
+  `@voltro/database` (and `voltro/database`) renamed four public exports along with the table behind them:
+
+  | was | is | |---|---| | `ImportRun` | `DataTransferRun` | | `describeImportRun` | `describeTransferRun` | | `IMPORT_RUNS_TABLE` | `DATA_TRANSFERS_TABLE` | | `_voltroImportRunsTable` | `_voltroDataTransfersTable` |
+
+  An EXPORT writes to this record now — the row carries a `direction` — so every one of those names described half of what it holds.
+
+  A `transform` codemod rewrites all four, alias-aware, from either module spelling. It also rewrites a hand-spelled `_voltro_data_imports` in a string, template or raw-SQL fragment, and that is the half worth stating: the four identifiers announce themselves as compile errors, while a query that addresses the table by name has nothing to fail on. The table itself moves with its rows via the declarative differ on every dialect.
+
+  This is filed apart from the transfer-protocol entry beside it deliberately. That one's codemod is `manual` and is about a CLI invocation living in scripts and CI jobs; this one is application source and is rewritten for you. Reading the first as covering both is what would leave a build broken with a note saying nothing in your source was affected.
+
+### Added
+
+- **@voltro/database, @voltro/data-transfer, @voltro/cli** — An import records WHETHER it staged, and a soft-dropped column says so in a drift refusal.
+
+  **`_voltro_data_imports.staged`.** The pre-upload preflight says what the instance WILL do; the run's own line says what it did — and that line is printed inside the instance, which is exactly where an operator using `--target api` cannot read it. So "we were told it would stage" and "it staged" were two claims with no way to close the gap between them from outside. The column is `null` for a mode where the question does not arise; `voltro data imports` and `GET /_voltro/admin/imports` both carry it.
+
+  **A soft-dropped column is named as one.** `<original>__dropped_<stamp>` is what the differ leaves behind when an app stops declaring a column — only the database that did the drop has it, so it drifts against every target. The refusal reported it as an ordinary missing column ("the value has nowhere to go"), which points at the TARGET's schema: the one place the fix does not lie. It now says where the column lives and how to reclaim it.
+
+### Fixed
+
+- **@voltro/data-transfer, @voltro/sql-sqlite, @voltro/database** — A successful `--mode replace --no-atomic` left a marker that refused the next boot.
+
+  Two defects, one visible symptom, and both were silent by construction.
+
+  **The clear was gated on the WRITE's condition.** `!(useLedger && ledger.truncated)` means "an earlier attempt already recorded this destructive run, do not write a second row" — correct on the write. Copied down to the clear its meaning inverts: `ledger.truncated` is set by the emptying step of THIS run, so on `--no-atomic` (the only mode where `useLedger` is true) the clear was skipped by the very run that wrote the marker.
+
+  **And a `Date` in a predicate is not bindable on sqlite.** `better-sqlite3` binds numbers, strings, bigints, buffers and null; the row path has coerced Dates since that store was written, and the eager-join compiler carried its own private copy of the fix, but `query` / `updateMany` / `deleteMany` bound the raw value. So every comparison of a timestamp column against a `Date` failed with `Failed to execute statement` — including the marker's clear, which swallows its errors ON PURPOSE (a store with no marker table must not fail an import over a bookkeeping row) and therefore said nothing. The retention sweep compares `lt(column, cutoff)` the same way.
+
+  Together: a fully successful replace left the marker standing, and the next boot REFUSED with "a destructive import did not finish" over a database that was completely fine. The one recovery is a command the operator has no reason to think they need. It stayed invisible because `atomic` defaults to true for `replace`, and because a staged replace writes no marker at all — two defaults hiding the one mode that exists for large, interruptible loads.
+
+  The coercion is shared now and applied at all three predicate sites, with a guard that fails on a fourth that forgets. A dry run also closes its trace row: a preview that finished instantly used to leave the record open, so a polling caller waited out its whole budget over a run that was long done.
+- **@voltro/cli** — `voltro codegen` declared twenty framework tables fewer than a boot.
+
+  The app half of this was fixed last release and looked like the whole thing. It was not: `codegen` derived the FEATURE MIX from the file list it had just walked, and that list is the entity/relations set — which contains no `*.workflow.tsx`, no `*.agent.ts`, no `*.cron.tsx`. So every feature flag came back false, and the dialect was never passed at all, taking `_voltro_cdc_offsets` with it. Measured on an app with two workflow files: 18 framework tables where the shared assembly produces 33.
+
+  It calls `assembleFrameworkTables({ root })` now — the same entry `voltro db plan/apply` uses, which detects the mix from the root rather than being handed one.
+
+  The parity guard moved with it. Comparing the two WALKS could not see this: both walks were right about files, and the divergence was introduced one layer past them. It compares the assembled SETS now, and runs codegen's own table function on a tree whose only feature signals are a workflow file and an agent file — a source assertion that the right function is CALLED cannot see a wrong argument handed to it, and a wrong argument is what this was.
+- **@voltro/cli** — `voltro data --help` advertised four subcommands out of nine.
+
+  It printed `<export|import|backup|restore>` while the command dispatched those four plus `imports`, `inspect`, `unpack`, `clear-replace-marker` and `clear-staging`. A quoted enumeration is read as exhaustive — the same failure `subcommandNames.ts` was written for after a `db` list cost two wrong conclusions — and the missing entry here is the one that answers "what is my import doing right now" for somebody who cannot reach the pod.
+
+  `subcommandHelpParity.test.ts` had listed `data` among the commands it could not check, loudly and correctly: there was no name list to check against. There is one now (`DATA_SUBCOMMANDS`), the dispatch is a keyed `Record`, so a subcommand with no name and a name with no handler are both compile errors, and the usage line is generated from the same array. `data` is out of the unchecked list.
+
+---
+
 ## [0.48.0] — 2026-08-22
 
 ### Added

package/dist/index.d.ts

@@ -824,6 +824,30 @@ export declare const clearTableRegistry: () => void;
 /** Test seam / dev-restart seam. */
 export declare const clearWriteRecorders: () => void;
 
+/**
+ * A predicate whose VALUES are bindable by the sqlite driver.
+ *
+ * Exported because it was module-private here, applied on the eager-join path
+ * only — and the plain `query` / `updateMany` / `deleteMany` paths bound the raw
+ * value. `better-sqlite3` refuses anything that is not a number, string, bigint,
+ * buffer or null, so every predicate comparing a timestamp column against a
+ * `Date` FAILED with `Failed to execute statement`, on the one dialect where the
+ * row path had a coercion sitting three files away.
+ *
+ * Found through the interrupted-replace marker: the clear swallows its errors by
+ * design (a missing marker table must not fail an import), so a successful
+ * `replace` left the marker standing and the NEXT BOOT REFUSED over a database
+ * that was fine. The retention sweep compares `lt(column, cutoff)` the same way.
+ *
+ * NOT a duplicate of `predicateCoercion.ts`, and worth keeping straight before
+ * anyone merges them: that one runs the other direction — it accepts a loose
+ * wire value (an epoch number, an ISO string) and normalises it INTO a `Date`
+ * for a temporal column. This one takes whatever the predicate ended up holding
+ * and makes it bindable by ONE driver. Both can apply to the same value, in that
+ * order.
+ */
+export declare const coercePredicateForSqlite: (predicate: Predicate) => Predicate;
+
 /**
  * The value to bind for `column`, given what the table declares it as.
  * Returns `value` unchanged whenever nothing unambiguous applies — including
@@ -834,6 +858,9 @@ export declare const coercePredicateValue: (columnType: ColumnType | undefined,
 /** Same, for the array-valued operators (`inSet` / `notInSet`). */
 export declare const coercePredicateValues: (columnType: ColumnType | undefined, values: ReadonlyArray<unknown>) => ReadonlyArray<unknown>;
 
+/** The value half of {@link coercePredicateForSqlite}. */
+export declare const coerceValueForSqlite: (value: unknown) => unknown;
+
 /**
  * Walk a predicate tree + yield every sub-query descriptor. The
  * store calls this before evaluating to know which sub-queries to
@@ -2006,6 +2033,8 @@ export declare const crdtText: () => ColumnBuilder<Uint8Array | null, "bytes">;
 /** The attribution on the current async stack, or `undefined` outside a request. */
 export declare const currentWriteAttribution: () => WriteAttribution | undefined;
 
+export declare const DATA_TRANSFERS_TABLE = "_voltro_data_transfers";
+
 /**
  * The application's `database` handle. Indexed by table name; each entry is
  * a `Query` over the table's row type AND a `using()` constraint over the
@@ -2423,6 +2452,23 @@ export declare interface DataStore {
     refreshChangeCaptureExclusions?(): Promise<ChangeCaptureExclusionRefresh>;
 }
 
+/** One transfer, as the inspector reads it back. */
+export declare interface DataTransferRun {
+    readonly id: string;
+    readonly direction: 'import' | 'export' | string;
+    readonly startedAt: Date;
+    readonly finishedAt: Date | null;
+    readonly mode: string;
+    readonly via: string;
+    readonly bundle: string | null;
+    readonly sourceFingerprint: string | null;
+    readonly tablesWritten: number;
+    readonly rowsWritten: number;
+    readonly failure: string | null;
+    /** Whether the run staged. `null` when the mode makes the question moot. */
+    readonly staged: boolean | null;
+}
+
 /** Calendar date without time. */
 export declare const date: () => ColumnBuilder<Date, "date", boolean>;
 
@@ -2750,14 +2796,6 @@ export declare const deriveTypeIdPrefix: (tableName: string) => string;
  */
 export declare const describeDriverError: (err: unknown) => string | undefined;
 
-/**
- * The line an operator reads.
- *
- * States the outcome first. "An import ran" is not the question — "did it
- * finish, and what did it bring" is.
- */
-export declare const describeImportRun: (run: ImportRun) => string;
-
 /**
  * The TYPE of every binding in a row, and never a value.
  *
@@ -2782,6 +2820,14 @@ export declare const describeImportRun: (run: ImportRun) => string;
  */
 export declare const describeRowBindings: (row: Readonly<Record<string, unknown>>) => string;
 
+/**
+ * The line an operator reads.
+ *
+ * States the outcome first. "An import ran" is not the question — "did it
+ * finish, and what did it bring" is.
+ */
+export declare const describeTransferRun: (run: DataTransferRun) => string;
+
 /**
  * Parse JSON-stringified array values back to JS arrays on the read
  * side. Tolerates `null` (NULL column → null in JS), pre-deserialised
@@ -3581,22 +3627,6 @@ export declare type IdSchemeInput = undefined | {
 
 export declare type IdSchemeKind = 'typeid' | 'ulid' | 'numeric' | 'snowflake' | 'custom';
 
-export declare const IMPORT_RUNS_TABLE = "_voltro_data_imports";
-
-/** One import, as the inspector reads it back. */
-export declare interface ImportRun {
-    readonly id: string;
-    readonly startedAt: Date;
-    readonly finishedAt: Date | null;
-    readonly mode: string;
-    readonly via: string;
-    readonly bundle: string | null;
-    readonly sourceFingerprint: string | null;
-    readonly tablesWritten: number;
-    readonly rowsWritten: number;
-    readonly failure: string | null;
-}
-
 export declare interface IndexAuditIssue {
     readonly kind: IndexAuditIssueKind;
     readonly table: string;
@@ -7794,6 +7824,16 @@ export declare const _voltroApiKeysTable: TableLike;
 
 export declare const _voltroCdcOffsetsTable: TableLike;
 
+/**
+ * One import, as an operator asks about it.
+ *
+ * Deliberately small. Everything here answers a question somebody has actually
+ * asked while looking at unexpected data — "where did this come from", "when",
+ * "did it finish" — and nothing here is a per-row fact, because that is the
+ * thing this replaces.
+ */
+export declare const _voltroDataTransfersTable: TableLike;
+
 /**
  * `_voltro_idempotency` — one row per (scope, key) for HTTP idempotency
  * (the `Idempotency-Key` header on REST routes). `scope` namespaces the key
@@ -7804,16 +7844,6 @@ export declare const _voltroCdcOffsetsTable: TableLike;
  */
 export declare const _voltroIdempotencyTable: TableLike;
 
-/**
- * One import, as an operator asks about it.
- *
- * Deliberately small. Everything here answers a question somebody has actually
- * asked while looking at unexpected data — "where did this come from", "when",
- * "did it finish" — and nothing here is a per-row fact, because that is the
- * thing this replaces.
- */
-export declare const _voltroImportRunsTable: TableLike;
-
 /**
  * `_voltro_kv` — the durable key-value store behind `ctx.kv` / the `Kv`
  * service when `KV_BACKEND=database` (the default for sql apps). One row per