@abloatai/ablo 0.44.0 → 0.46.0

package/AGENTS.md

@@ -87,4 +87,23 @@ Claims live on a callable namespace beside `create` / `update` / `retrieve`. Eve
 - `ablo.<model>.claim.release({ id })` — release a claim early.
 - `ablo.<model>.claim.reorder({ id, order })` — reorder the waiting queue.
 
+Keep admission behavior together for anything beyond the default wait:
+
+```ts
+const claim = await ablo.tasks.claim({
+  id,
+  contention: {
+    mode: 'skip', // use 'wait' with maxDepth / timeoutMs when waiting is useful
+    onStatus(event) {
+      if (event.type === 'skipped') console.warn(event.error.message);
+    },
+  },
+});
+if (!claim) return; // another participant already owns the work
+```
+
+`onStatus` receives typed `queued`, `granted`, `skipped`, and `failed` events.
+It is request-scoped; use `claim.state` / `claim.queue` for the shared reactive
+view.
+
 Most users declare a schema and write through `ablo.<model>.update({ id, data })`.

package/CHANGELOG.md

@@ -1,5 +1,49 @@
 # Changelog
 
+## 0.46.0
+
+### Pre-existing rows arrive on their own
+
+Connecting a database that already holds data no longer leaves those rows
+invisible until something touches them. Ablo snapshots the pre-existing rows
+automatically, `ablo connect check` refuses to report ready until that
+snapshot completes, and `ablo status --json` exposes the progress as
+`initialSnapshot.status`: `loading`, `retrying` with the underlying error, or
+`complete`. Keep an existing read fallback in place until the status reads
+`complete`. Row-touch backfill scripts are unnecessary; the snapshot is the
+engine's job.
+
+## 0.45.0
+
+### Claim admission is authoritative
+
+A claim used to return a local handle immediately, before the server had
+granted anything, so two agents on different server instances could each
+believe they held the same row. Every claim now waits for the server's grant
+or rejection, and the server fails closed when the shared lease store is
+unavailable rather than admitting claims it cannot coordinate. A two-server
+end-to-end regression pins the behavior.
+
+### Contention has a lifecycle you can watch
+
+The new `contention` option names what happens when the row is already held:
+
+```ts
+const claim = await ablo.tasks.claim({
+  id,
+  contention: {
+    mode: 'skip',
+    onStatus(event) {
+      // queued | granted | skipped | failed
+    },
+  },
+});
+```
+
+`{ mode: 'skip' }` resolves `null` instead of waiting, and `onStatus` reports
+the attempt as it moves. `queue: true` and `queue: false` remain as
+compatible spellings of the two modes.
+
 ## 0.44.0
 
 ### A scope denial names the wall it hit

package/docs/agents.md

@@ -116,9 +116,9 @@ await ablo.tasks.claim.queue({ id: taskId });   // the FIFO wait-line behind the
 await ablo.tasks.claim.reorder({ id: taskId, order: line }); // re-rank the line (privileged)
 ```
 
-Think of it as a queue per row — a durable, inspectable, reorderable lease line
-("SQS for entity contention"). Use `{ queue: false }` for fail-fast dedup: *if
-someone else has this job, skip it.*
+Think of it as a queue per row — a durable, inspectable, reorderable lease
+line. Use `contention: { mode: 'skip' }` for fail-fast dedup: *if someone else
+has this job, skip it.*
 
 ## Messaging between agents
 

package/docs/client-behavior.md

@@ -152,7 +152,9 @@ the latest row, then hands you the fresh row — so you can't overwrite a change
 see. Options on the claim:
 
 - default `claim` waits in the fair queue and re-reads before handing you the row;
-- `{ queue: false }` rejects with `AbloClaimedError` instead of queuing;
+- `{ queue: false }` resolves `null` when another participant already holds the
+  target; two clients with the same participant identity are re-entrant, not
+  contenders;
 - `{ maxQueueDepth }` rejects if the wait line is already too deep.
 
 While waiting, schema clients learn when the claim clears from the live claim
@@ -172,7 +174,7 @@ All SDK errors extend `AbloError` and carry a stable `type`.
 | `AbloValidationError` | Invalid input or unsupported request shape. |
 | `AbloServerError` | Server-side 5xx. Retry with backoff if the operation is idempotent. |
 | `AbloStaleContextError` | Write was based on stale `readAt` state. Re-read and retry. |
-| `AbloClaimedError` | An active claim conflicted with `{ queue: false }`, the queue was too deep, or a claim wait timed out. |
+| `AbloClaimedError` | A write conflicted with another participant's active claim, the queue was too deep, or a claim wait timed out. |
 
 ```ts
 import { AbloClaimedError } from '@abloatai/ablo';

package/docs/coordination.md

@@ -57,7 +57,7 @@ See [claiming part of a row](#claiming-part-of-a-row).
 > from outside with `signal` (an `AbortSignal`; rejects
 > `claim_wait_aborted`), bound the line you'll join with `maxQueueDepth`
 > (`queue_too_deep`), or skip waiting entirely with `queue: false` — the
-> try-claim, which resolves `null` when the target is held (a declined try
+> try-claim, which resolves `null` when the target is held (skipped work
 > is not an error) and takes no place in line. For
 > callers that manage the wait themselves, the ticket surface remains:
 > `ablo.claims.get({ claimId })` polls a ticket to its grant,
@@ -94,6 +94,12 @@ claim](#writing-under-a-claim)), and the [errors](#errors) you can catch.
 >
 > Now `agent-0` holds while `agent-1`/`agent-2` queue in FIFO order and drain in
 > turn. See [sessions](./sessions.md#agent-sessions-rk_) for the minting flow.
+>
+> **Testing exclusion:** mint two sessions with different `agent.id` values,
+> assert those values differ, let A acquire the row, and inspect
+> `claim.state({ id })` before B calls
+> `claim({ id, contention: { mode: 'skip' } })`. B must receive `null`.
+> Creating two clients from the same key tests re-entrancy, not contention.
 
 ---
 
@@ -317,14 +323,15 @@ four axes. `claim({ id })` alone is a complete call; each axis is opt-in.
 | `options.description` | `string` | no | Peer-visible description of the work, shown to observers (default `'editing'`). |
 | `options.meta` | `object` | no | App-defined structured metadata, carried verbatim to every participant observing the claim. Declare its shape once on `Register`'s `ClaimMeta` slot. |
 
-*How you wait* — admission to the line:
+*How you handle contention*:
 
 | name | type | required | description |
 |---|---|---|---|
-| `options.queue` | `boolean` | no | `true` (default) queues and waits for the lease. `false` is the try-claim: if another participant holds the row it resolves `null`: an expected outcome, not an error, so claim-or-skip dedup reads `if (!claim) return` (waiting would double-process). Who holds it stays readable via `claim.state`. A *write* to a held row still rejects `entity_claimed`. |
-| `options.maxQueueDepth` | `number` | no | Backpressure: reject with `AbloClaimedError('queue_too_deep')` instead of joining a line already `>= maxQueueDepth` deep. Omit to wait however deep the queue is. |
-| `options.waitTimeoutMs` | `number` | no | Cap on how long a queued claim waits for its grant before rejecting with `AbloClaimedError('grant_timeout')`. Omit to wait as long as the line takes. Same meaning on both transports; over HTTP a timed-out wait also leaves the line. |
-| `options.signal` | `AbortSignal` | no | Abort a pending wait from outside: a cancelled agent task or an unmounted component takes its queued claim with it. Rejects with `AbloClaimedError('claim_wait_aborted')`; over HTTP the abort also leaves the line. Ignored once the grant has arrived, release a held lease instead. |
+| `options.contention` | `Claim.ContentionOptions` | no | Keeps the response to a busy target together: `{ mode: 'wait', maxDepth?, timeoutMs?, signal?, onStatus? }`. Use `mode: 'skip'` for claim-or-skip dedup; a foreign holder resolves the claim as `null`. |
+| `options.queue` | `boolean` | no | Compatibility shorthand: `true` waits and `false` skips. Prefer `contention` when configuring more than the mode. |
+| `options.maxQueueDepth` | `number` | no | Legacy flat spelling of `contention.maxDepth`. Prefer `contention` for new code. |
+| `options.waitTimeoutMs` | `number` | no | Legacy flat spelling of `contention.timeoutMs`. Prefer `contention` for new code. |
+| `options.signal` | `AbortSignal` | no | Legacy flat spelling of `contention.signal`. Prefer `contention` for new code. |
 
 *How long you hold* — the lease:
 
@@ -333,6 +340,53 @@ four axes. `claim({ id })` alone is a complete call; each axis is opt-in.
 | `options.ttl` | `Duration` | no | Crash-cleanup floor. Rarely set: the lease renews while your connection is alive, so it only matters once you go silent. |
 | `options.heartbeat` | `true \| Duration \| { every?, onBeat?, onLost? }` | no | Keep the lease alive for work that outlives the TTL: `true` beats every third of the TTL, a duration sets the cadence, and the structured form carries the cadence and both callbacks in one place: `onBeat` fires after every successful beat (chiefly `queueDepth`, the pressure signal), `onLost` once if a beat learns the lease is gone. The loop stops on release. |
 
+The request-scoped `onStatus` callback receives one discriminated event. It is
+observational: an exception in UI or telemetry code never changes the claim
+attempt.
+
+| event | meaning | claim promise |
+|---|---|---|
+| `queued` | this request joined the wait line | remains pending |
+| `granted` | this request owns the lease | resolves with the claim |
+| `skipped` | `mode: 'skip'` found another participant holding the target | resolves `null` |
+| `failed` | the attempt could not complete, for example timeout, cancellation, authorization, or connectivity | rejects with `event.error` |
+
+```ts
+const claim = await ablo.tasks.claim({
+  id,
+  contention: {
+    mode: 'wait',
+    maxDepth: 3,
+    timeoutMs: 30_000,
+    onStatus(event) {
+      if (event.type === 'queued') {
+        console.log(`${event.ahead} participant(s) ahead`);
+      } else if (event.type === 'granted') {
+        console.log(event.waited ? 'your turn' : 'granted immediately');
+      } else {
+        console.warn(event.error.code, event.error.message);
+      }
+    },
+  },
+});
+```
+
+For claim-or-skip work, make the caller's intent explicit and keep its status
+observer beside the decision:
+
+```ts
+const claim = await ablo.tasks.claim({
+  id,
+  contention: {
+    mode: 'skip',
+    onStatus: (event) => {
+      if (event.type === 'skipped') metrics.increment('claim.skipped');
+    },
+  },
+});
+if (!claim) return;
+```
+
 The high-level `claim` queues by default, so on contention you either get the row
 when your turn arrives or one of the [queue errors](#errors) (`claim_lost`,
 `grant_timeout`).
@@ -447,6 +501,13 @@ ablo.<model>.claim.state({ id })
 Read who's currently working on a row, for observers and UI. Synchronous and
 reactive (it reads the local coordination snapshot). Never blocks.
 
+The first call also starts row-scoped observation. Because that subscription is
+asynchronous, an imperative script may briefly read `null` before the reactive
+snapshot arrives; subscribe to changes or wait for the expected holder when the
+observation itself is the test. Late subscriptions are backfilled across server
+instances, and a skipped conflict attempt seeds its authoritative holder
+summary into the same snapshot immediately.
+
 **You don't subscribe to anything first.** Reading or claiming a row
 automatically enrolls you in that row's sync group: reading it (including
 `retrieve`/`get`, or `claim.state` itself) gives you **read-interest**, and
@@ -552,16 +613,22 @@ decide the wait isn't worth it.
 |---|---|---|---|
 | `id` | `string` | yes | The row id. |
 
-**Returns** — a list envelope. `data` contains the queued
-[claim state objects](#the-claim-state-object) in promotion order (head first), excluding
-the active holder; `[]` when no one is waiting.
+**Returns** — a structured queue snapshot:
+
+- `waiting` — queued [claim state objects](#the-claim-state-object) in
+  promotion order, excluding the active holder;
+- `next` — the first waiter, or `null`;
+- `size` — how many participants are waiting;
+- `data` — the same array as `waiting`, retained as the standard list-envelope
+  member for compatibility.
 
 **Example**
 
 ```ts
-const { data: waiting } = ablo.weatherReports.claim.queue({ id: 'report_stockholm' });
-console.log(`${waiting.length} ahead of you`);
-console.log(waiting.map((i) => i.heldBy));
+const line = ablo.weatherReports.claim.queue({ id: 'report_stockholm' });
+console.log(`${line.size} waiting`);
+console.log(`next: ${line.next?.heldBy ?? 'nobody'}`);
+console.log(line.waiting.map((claim) => claim.heldBy));
 ```
 
 ### `claim.release`

package/docs/data-sources.md

@@ -74,6 +74,19 @@ yourself. Rotate the scoped passwords any time with `ablo connect rotate`.
 The rest of this page is what that command sets up, step by step, for when you want
 to run it by hand or review exactly what changes.
 
+### Existing rows load automatically
+
+When Ablo creates the replication slot, it takes a consistent initial snapshot of
+every mapped table in the publication before following new changes. Rows that
+predate `ablo connect` therefore become available to `retrieve`, `list`, and
+reactive `local.*` reads without an application backfill.
+
+Run `ablo connect check` before removing an existing HTTP/database read fallback.
+It reports the initial load as `loading` until the snapshot is complete. Do not
+write a script that updates every row to make it visible: an Ablo update requires
+the row to be visible already, and touching application rows is neither necessary
+nor a safe bootstrap mechanism.
+
 ## The setup, step by step
 
 ### 1. Enable logical decoding
@@ -172,6 +185,8 @@ checklist or the precise per-item fix:
   `REPLICA IDENTITY FULL`) so `UPDATE`/`DELETE` can replicate
 - the writer role is DML-ready — scoped, non-superuser, with the idempotency
   ledger in place
+- the initial snapshot is complete, so rows that existed before connecting are
+  available to Ablo reads
 
 Because Ablo checks from its own network, a database your own machine can't reach —
 IPv6-only, IP-allowlisted, behind a VPN — still verifies. Re-run it until every
@@ -195,8 +210,8 @@ export const ablo = Ablo({
 ```
 
 The Ablo schema describes **only your synced, collaborative models** — the rows
-Ablo coordinates and fans out in realtime. It is *not* your whole-database schema
-and does *not* replace your `schema.prisma` (or Drizzle schema). Your auth,
+Ablo coordinates and fans out in realtime. It is _not_ your whole-database schema
+and does _not_ replace your `schema.prisma` (or Drizzle schema). Your auth,
 billing, and other tables stay in your own ORM schema, owned by your own
 migrations. `ablo check` reflects this — it reports tables you didn't declare as
 "ignored / owned by you," which is exactly right.
@@ -226,13 +241,13 @@ state means and when to wait.
 
 This is the complete list. Nothing else.
 
-| Object | What it is | Owned by |
-|---|---|---|
-| `ablo_publication` | A publication naming the tables Ablo reads and confirms against. | You create it (step 2). |
-| `ablo_replicator` role | A `REPLICATION` + `SELECT` role Ablo reads and confirms through. | You create it (step 2). |
-| `ablo_writer` role | A scoped DML role Ablo writes your rows through: row DML + ledger, nothing more. | You create it (step 2). |
-| Replication slot | A logical slot Ablo subscribes through to track its WAL position. | Ablo's runtime creates it on first connect. |
-| `wal_level = logical` | A server setting that **requires a restart**. | You set it (step 1). |
+| Object                 | What it is                                                                       | Owned by                                    |
+| ---------------------- | -------------------------------------------------------------------------------- | ------------------------------------------- |
+| `ablo_publication`     | A publication naming the tables Ablo reads and confirms against.                 | You create it (step 2).                     |
+| `ablo_replicator` role | A `REPLICATION` + `SELECT` role Ablo reads and confirms through.                 | You create it (step 2).                     |
+| `ablo_writer` role     | A scoped DML role Ablo writes your rows through: row DML + ledger, nothing more. | You create it (step 2).                     |
+| Replication slot       | A logical slot Ablo subscribes through to track its WAL position.                | Ablo's runtime creates it on first connect. |
+| `wal_level = logical`  | A server setting that **requires a restart**.                                    | You set it (step 1).                        |
 
 Operational reality you should know up front:
 
@@ -254,7 +269,7 @@ have.
 
 ## What Ablo stores on its side
 
-Your schema *definition* (model names, fields, types — pushed with `ablo push`),
+Your schema _definition_ (model names, fields, types — pushed with `ablo push`),
 your hashed API keys, a safe projection of the connection registration (host,
 database, schema — the connection string itself is sealed and never echoed back),
 the replication slot position, and the ordered transaction log that drives sync and

package/docs/debugging.md

@@ -245,8 +245,18 @@ The same stable code covers two different enforcement layers, so inspect
 - `database_row_level_security`: Ablo's capability gate allowed the operation,
   but Postgres rejected it under the customer table's RLS policy.
   `details.databaseSessionContext` shows the organization, project, branch,
-  participant kind, user principal, and custom session-setting values applied
-  to that transaction.
+  participant kind, user principal, and the complete built-in-plus-custom
+  session-setting values configured for that transaction.
+  `customSessionSettings` isolates only the mappings declared by the schema;
+  an empty object there does not mean built-in settings such as
+  `app.current_org_id` were absent.
+
+Do not respond by changing a tenant policy to `USING (true)` or granting
+`BYPASSRLS`. Compare the row's tenant value with
+`databaseSessionContext.sessionSettings.app.current_org_id`. On CREATE, Ablo
+server-stamps the authenticated organization into the model's row-local tenancy
+field; a missing value is a server/version fault to report with `requestId`, not
+a requirement to make the column nullable or open the policy.
 
 Every rejected live commit carries `requestId` on the thrown error and
 `request_id` in its JSON form and warning line:

package/docs/examples/agent-human.md

@@ -54,15 +54,17 @@ export async function markDone(taskId: string) {
   if (!task) return { status: 'not_found' };
 
   try {
-    // queue: false → don't queue behind a current holder. If someone already
-    // holds the row, claim rejects with AbloClaimedError (caught below), so the
-    // agent yields instead of waiting. Omit it, or pass queue: true, to queue
-    // behind them. description → the label observers see while we work.
-    await using claim = await ablo.tasks.claim({
+    // queue: false → don't queue behind a current holder. If another
+    // participant holds the row, claim resolves null, so the agent yields
+    // instead of waiting. Omit it, or pass queue: true, to queue behind them.
+    const acquired = await ablo.tasks.claim({
       id: taskId,
       queue: false,
       description: 'marking_done',
     });
+    if (!acquired) return { status: 'yielded' };
+
+    await using claim = acquired;
     if (claim.data.status === 'done') return { status: 'noop' };
 
     // Inside an active claim, `update` is stale-checked automatically: the SDK
@@ -89,7 +91,7 @@ export async function markDone(taskId: string) {
 
     return { status: 'done', task: updated };
   } catch (err) {
-    // Someone already holds the row — yield this run and let them finish.
+    // The lease was lost or a foreign holder rejected the write.
     if (err instanceof AbloClaimedError) return { status: 'yielded' };
     // A newer version was saved while we held the claim. The stale-check
     // rejected our commit, so nothing was overwritten — re-run on fresh data.

package/docs/examples/server-agent.md

@@ -29,24 +29,43 @@ const schema = defineSchema({
   }),
 });
 
-const ablo = Ablo({
+const control = Ablo({
   schema,
   apiKey: process.env.ABLO_API_KEY,
-  transport: 'http',
 });
 
-export async function completeTask(taskId: string) {
+async function clientForWorker(workerId: string) {
+  const { token } = await control.sessions.create({
+    agent: { id: workerId },
+    can: { tasks: ['read', 'update'] },
+  });
+  return Ablo({ schema, apiKey: token, transport: 'http' });
+}
+
+export async function completeTask(taskId: string, workerId: string) {
+  // Participant identity comes from this worker-specific session. Two clients
+  // made directly from the same root key are re-entrant, not contenders.
+  const ablo = await clientForWorker(workerId);
   await ablo.ready();
 
   const task = await ablo.tasks.get({ id: taskId });
   if (!task) return { status: 'not_found' };
 
-  await using claim = await ablo.tasks.claim({
+  const acquired = await ablo.tasks.claim({
     id: taskId,
-    queue: false,
+    contention: {
+      mode: 'skip',
+      onStatus(event) {
+        if (event.type === 'skipped') {
+          console.info('task already owned', event.error.code);
+        }
+      },
+    },
     description: 'completing',
   });
+  if (!acquired) return { status: 'already_claimed' };
 
+  await using claim = acquired;
   const updated = await ablo.tasks.update({
     id: claim.data.id,
     data: { status: 'done' },
@@ -67,7 +86,7 @@ The two options on the claim:
 
 - `queue: false` — skip this record if another claim is already in progress,
   rather than queueing behind it. Fail-fast dedup: *if someone else has this job,
-  skip it.* (The default queues.)
+  skip it.* It resolves `null`; it does not throw. (The default queues.)
 - `description: 'completing'` — a readable label for what your worker is doing,
   visible to anyone reading `claim.state({ id })`.
 

package/docs/quickstart.md

@@ -304,8 +304,9 @@ await using handle = await ablo.weatherReports.claim({ id: 'weather_stockholm' }
 await ablo.weatherReports.update({ id: handle.data.id, data: { status: 'ready' } });
 ```
 
-Use `{ queue: false }` on `claim` when work should be skipped instead of queued
-behind an active holder.
+Use `contention: { mode: 'skip' }` when work should be skipped instead of
+queued behind an active holder. Add `onStatus` inside that object when the
+attempt should also update telemetry or UI.
 
 ## Next steps
 

package/docs/session-settings.md

@@ -54,6 +54,14 @@ context, whether or not you map anything:
 If your policies read these names directly, you need no mapping at all — this
 page is for the case where they read different ones.
 
+For a mutable model with row-local tenancy, Ablo also puts the authenticated
+organization into the CREATE operation as `organizationId`; the source adapter
+maps that field to the model's tenancy column (normally `organization_id`).
+Callers do not supply it, and the column does not need a SQL default. A default
+from `app.current_org_id` can be useful as defense in depth, but it is not a
+substitute for the tenant policy and you should never loosen RLS to make an
+Ablo write pass.
+
 `app.current_user_id` is worth reading twice, because it has three states rather
 than two. It carries a person's id when a person is behind the write. It carries
 `*` when a backend credential is acting as the organization itself, which is the

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@abloatai/ablo",
-  "version": "0.44.0",
+  "version": "0.46.0",
   "description": "The public Ablo SDK for coordinated reads, commits, claims, observation, and reactive applications.",
   "license": "Apache-2.0",
   "type": "module",
@@ -124,8 +124,8 @@
     "directory": "packages/ablo"
   },
   "dependencies": {
-    "@abloatai/humans": "^0.44.0",
-    "@abloatai/transaction": "^0.44.0"
+    "@abloatai/humans": "^0.46.0",
+    "@abloatai/transaction": "^0.46.0"
   },
   "peerDependencies": {
     "ai": "^6.0.0 || ^7.0.0",