@abloatai/ablo 0.16.3 → 0.17.0

package/CHANGELOG.md

@@ -1,5 +1,39 @@
 # Changelog
 
+## 0.17.0
+
+### Minor Changes
+
+- **Bring-your-own database is now one model.** Ablo connects to your Postgres and
+  never operates it. There used to be two confusing BYO paths, and the
+  connection-string one would create roles, force row-level security, transfer
+  table ownership, and push you to run `ablo migrate` before anything worked. That
+  cascade is gone. Ablo now follows the shape every serious "sync over your own
+  Postgres" engine uses (ElectricSQL, PowerSync, Zero): it reads your database via
+  Postgres logical replication and never runs DDL, creates roles, forces RLS, or
+  rewrites your `DATABASE_URL`. You own your schema; Ablo reads it.
+  - **New: `ablo connect`.** One command prints the exact, copy-pasteable setup for
+    your own Postgres — enable `wal_level=logical`, create the `ablo_publication`
+    publication and a least-privilege `ablo_replicator` role — and
+    `ablo connect --check` validates readiness (wal level, publication, replication
+    grant, replica identity). This is the single supported way to connect a real
+    database.
+  - **`ablo migrate` left the happy path.** It no longer creates roles, transfers
+    ownership, or rewrites your connection string, and `ablo dev` no longer attempts
+    a scoped-role creation on every watch loop. `migrate` is now an optional escape
+    hatch for generating starter DDL (`--dry-run` prints the SQL).
+  - **Clearer failures.** `ablo push` permission errors lead with the server's actual
+    reason code and per-code remediation instead of a generic "needs `schema:push`
+    scope," and the schema-conflict message names which environment/version a prior
+    push came from and when.
+  - **Logical-replication runtime is in Preview.** The setup (`ablo connect`) and the
+    connection model are live; the server-side WAL consumer that streams your changes
+    is implemented and journey-tested but not yet generally available.
+
+  The previous connection-string-operate and adapter/outbox modes are demoted to a
+  clearly-labeled **Legacy / not recommended** section — they still work, but new
+  integrations should use logical replication.
+
 ## 0.16.3
 
 ### Patch Changes

package/dist/BaseSyncedStore.d.ts

@@ -702,7 +702,9 @@ export declare class BaseSyncedStore<TCollaboration extends EventMap<TCollaborat
      * sync-group mutations). Does NOT schedule a flush — callers decide
      * whether to debounce (live) or flush atomically (catch-up frame).
      */
-    protected enqueueDelta(delta: SyncDelta): boolean;
+    protected enqueueDelta(delta: SyncDelta, options?: {
+        authoritative?: boolean;
+    }): boolean;
     /** Debounce a flush for live single-delta traffic. */
     protected scheduleDeltaFlush(): void;
     /**

package/dist/BaseSyncedStore.js

@@ -1713,7 +1713,25 @@ export class BaseSyncedStore {
     applyDeltaFrame(deltas) {
         let enqueuedAny = false;
         for (const delta of deltas) {
-            if (this.enqueueDelta(delta))
+            // A delta_batch frame is the server's AUTHORITATIVE, ordered answer to
+            // "everything in my stream after cursor C" (reconnect/catch-up replay or
+            // post-bootstrap drain). Apply every delta it carries — do NOT subject it
+            // to the live-traffic watermark dedup (`id <= applied`).
+            //
+            // That watermark is only valid under in-order delivery, and reconnect
+            // breaks the assumption: an in-flight LIVE broadcast for a gap delta can
+            // land out of order BEFORE the catch-up fills the ids below it (e.g. the
+            // server acks a write, then the test/client reconnects, then that write's
+            // pending broadcast arrives on the fresh socket — id 4 live before the
+            // catch-up's [2,3,4]). Applying id 4 advances `applied` to 4, and the
+            // watermark would then drop 2 and 3 from the catch-up as "already seen" —
+            // a poisoned gap and a cursor that lies (applied=4 with rows 2,3 absent).
+            //
+            // Re-applying a delta the live path already applied is safe: the
+            // downstream `Database.processDeltaBatch` + `SyncClient.applyDeltaBatchToPool`
+            // are idempotent (echo detection, no row resurrection, conflict
+            // resolution), so the redundant id 4 is a no-op while 2 and 3 land.
+            if (this.enqueueDelta(delta, { authoritative: true }))
                 enqueuedAny = true;
         }
         if (!enqueuedAny)
@@ -1734,10 +1752,15 @@ export class BaseSyncedStore {
      * sync-group mutations). Does NOT schedule a flush — callers decide
      * whether to debounce (live) or flush atomically (catch-up frame).
      */
-    enqueueDelta(delta) {
-        // Dedup guard — skip already-processed deltas
-        if (delta.id > 0 && delta.id <= this.highestProcessedSyncId)
+    enqueueDelta(delta, options = {}) {
+        // Dedup guard — skip already-processed deltas. The `applied` watermark is a
+        // valid skip threshold ONLY for in-order live traffic; an authoritative
+        // catch-up frame bypasses it (see `applyDeltaFrame`) so an out-of-order
+        // live delta that advanced the watermark can't cause the frame's lower ids
+        // to be silently dropped.
+        if (!options.authoritative && delta.id > 0 && delta.id <= this.highestProcessedSyncId) {
             return false;
+        }
         // Confirm awaiting transactions via sync ID threshold (before batching)
         this.syncClient.onDeltaReceived(delta.id);
         // Update version vector