@voltro/database 0.54.0 → 0.56.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/sql.d.ts CHANGED
@@ -126,27 +126,6 @@ export declare interface AppliedOp {
126
126
  */
127
127
  export declare const applyNamespacedSchema: (tables: ReadonlyArray<AnyTable>, namespace: string, dialect?: DialectId, options?: SchemaApplyOptions) => Effect.Effect<void, never, SqlClient.SqlClient>;
128
128
 
129
- /**
130
- * Execute a `MigrationPlan` against the connected database.
131
- *
132
- * Behaviour:
133
- *
134
- * 1. If the plan has ANY blocked operation, throw before touching
135
- * the DB. Callers should run `voltro db plan` first + resolve.
136
- * 2. Acquire the advisory lock (per-dialect; postgres v1).
137
- * 3. Bootstrap the resume ledger and finish any run a crash left behind
138
- * (see `resolveInterruptedRun`).
139
- * 4. Record every operation that will run OUTSIDE a transaction, then for
140
- * each op in plan order: mark it started, emit the DDL, run any backfill,
141
- * mark it applied.
142
- * 5. Write a row to `_voltro_migration_plans` with the post-state
143
- * fingerprint + operations JSON + duration + environment, and clear the
144
- * ledger.
145
- * 6. Release the advisory lock.
146
- *
147
- * The return value is the `AppliedMigration` row — the same shape
148
- * used by the inspect RPC + the cloud dashboard timeline.
149
- */
150
129
  export declare const applyPlan: (sql: SqlClient.SqlClient, plan: MigrationPlan, ctx: ApplyPlanCtx) => Effect.Effect<AppliedMigration, SqlError_2, SqlClient.SqlClient>;
151
130
 
152
131
  export declare interface ApplyPlanCtx {
@@ -173,10 +152,15 @@ export declare interface ApplyPlanCtx {
173
152
  */
174
153
  readonly lockSchema?: string;
175
154
  /**
176
- * Re-plan against the LIVE schema the convergence proof.
155
+ * Re-plan against the LIVE schema. Called TWICE, for two different questions.
156
+ *
157
+ * **Under the lock, BEFORE any DDL** — because the plan was computed before
158
+ * the lock was held, and two writers booting at once both plan against the
159
+ * same live state. The loser would otherwise apply a plan for a database that
160
+ * no longer exists.
177
161
  *
178
- * `applyPlan` calls this once, after the DDL and BEFORE it records the
179
- * fingerprint. A plan that converged re-plans to zero operations; anything
162
+ * **After the DDL and BEFORE the fingerprint is recorded** the convergence
163
+ * proof. A plan that converged re-plans to zero operations; anything
180
164
  * left is DDL that ran without error and did not take effect, and the apply
181
165
  * fails rather than recording a fingerprint that describes a database state
182
166
  * that does not exist.
@@ -196,6 +180,13 @@ export declare interface ApplyPlanCtx {
196
180
  * report drift that isn't there. A caller that cannot re-plan cannot prove it
197
181
  * applied anything.
198
182
  *
183
+ * **It has to answer about the schema as it is AT THE MOMENT OF THE CALL.** A
184
+ * fake that returns a constant is fine for the second call and wrong for the
185
+ * first: answering "nothing to do" before the DDL makes `applyPlan` skip the
186
+ * very plan under test. What the caller's own unblock decision (`unblockLossy`)
187
+ * did to the plan is NOT re-derived here — `applyPlan` carries it forward
188
+ * itself, because the planner has no memory of it.
189
+ *
199
190
  * **USE THE `sql` THIS HANDS YOU.** It is the connection the apply ran on, and
200
191
  * that is the point: the convergence proof has to observe the session that
201
192
  * made the change. A re-plan that opens its OWN connection is asking a