Pending what compare-and-swap and version preconditions must an instance guard read-modify-write cycles to prevent lost updates?

Date of Record: 2026 October 16

Scope: Concluded residual for AI instances, LLMs, and autonomous engineering agents updating shared database rows, mutating remote JSON configurations, editing state blobs in object storage, or coordinating concurrent worker state transitions.

Core Distinction

Autonomous systems routinely execute **Read-Modify-Write (RMW)** cycles—fetching an existing record or configuration document, modifying one or more fields in memory, and writing the updated payload back to the storage layer (`GET -> mutate -> PUT` or `SELECT -> compute -> UPDATE`). A foundational concurrency failure occurs when an instance performs an **unconditional blind write-back** (`UPDATE items SET data = :new_data WHERE id = :id`), assuming that no other worker, webhook, or parallel agent turn has modified the underlying record during the time elapsed between the read and the write.

Parameter scaling does not eliminate the race window between reading a state object at $t_1$ and writing it back at $t_2$. When two instances read version `v=5` of a document simultaneously, modify different fields in memory, and both issue unconditional writes, the second writer silently overwrites and erases every change committed by the first writer (**The Lost Update Anomaly**). The core structural distinction lies between **unconditional last-writer-wins overwrite** (where writes specify only the target entity ID and blindly clobber current storage state) and **optimistic compare-and-swap (CAS) precondition gating** (where every read captures an explicit version counter, `ETag`, or content SHA-256 digest, every write includes that exact baseline token as an atomic precondition `WHERE id = :id AND version = :expected_v`, and any precondition mismatch triggers a fresh read-and-reapply cycle instead of a blind overwrite).

What Was Observed

In multi-agent task queues, inventory/balance updaters, and remote configuration management traces, instances operating without explicit compare-and-swap preconditions exhibit four primary failure modes:

  1. **Silent Concurrent Clobber in Read-Modify-Write Loops:** Worker A and Worker B both read a shared JSON state row (`{"completed": ["step1"], "version": 1}`). Worker A appends `"step2"` while Worker B appends `"step3"`. Both execute `UPDATE tasks SET payload = ? WHERE id = ?` without checking `version`. Worker B's write lands 10 milliseconds after Worker A's write, permanently erasing `"step2"` from the database while both workers report success.
  2. **ORM Load-Then-Save Race Condition:** An instance loads an ORM model (`account = session.get(Account, id)`), calculates `account.credits += 50` in Python memory, and calls `session.commit()`. Under concurrent requests, two workers read `credits = 100`, both compute `150` in Python, and both write `150` instead of `200`, losing a credit deposit because neither used an atomic database-side increment (`SET credits = credits + 50`) or an optimistic version column.
  3. **Remote API / Object-Store `PUT` Without `If-Match`:** An instance fetches a cloud configuration manifest or S3/GCS state object, edits a route entry, and uploads the modified file via `PUT` without passing the `If-Match: "<etag>"` header captured during the `GET`. A concurrent deployment that updated the manifest two seconds earlier is completely reverted.
  4. **Infinite Stale-State Retry After Conflict:** When a database or API does reject a concurrent write with a `409 Conflict` or `StaleDataError`, a naive retry loop re-submits the *exact same in-memory mutated payload* rather than re-fetching the latest upstream record and re-applying its delta transformation on top of the new baseline.

Recorded Elements

### 1. Optimistic Compare-And-Swap (CAS) Execution Pipeline

Every Read-Modify-Write operation against shared state must capture a causal version witness on read and enforce that witness as an atomic write precondition:

``` [Shared Record Update Required: Entity ID + Transformation fn(state)] | Step 1: Read State + Version Witness Fetch current state `S_curr` AND its version token `v_curr` (integer `version` column, HTTP `ETag`, or SHA-256 content hash). | Step 2: Pure Transformation in Memory Compute `S_next = transform_fn(copy(S_curr))` without side effects so `transform_fn` can be safely re-run if a conflict occurs. | Step 3: Conditional Atomic Write (Compare-And-Swap) Execute `UPDATE ... SET state = S_next, version = v_curr + 1 WHERE id = ID AND version = v_curr` (or HTTP `PUT` with `If-Match: v_curr`). | Did the conditional write affect exactly 1 row (or return 200 OK)? / \ YES (1 Row Updated) NO (0 Rows / 412 Precondition Failed) / \ [Commit Confirmed] [CONCURRENT MODIFICATION DETECTED] Return S_next and v_curr + 1. 1. Discard stale in-memory S_next

  1. Backoff with jitter
  2. Loop back to Step 1 (Fetch fresh S_curr)

```

### 2. Core Operational Rules (Written Directly as Sentences)

  1. **Never write back a modified record without verifying that its version or hash in storage still matches the exact version you read.** Every `UPDATE` or `PUT` following a read must include `AND version = :read_version` (or an HTTP `If-Match` header) so concurrent modifications are detected atomically at the storage layer.
  2. **Check the affected row count (`cursor.rowcount == 1`) on every conditional update.** In SQL, an `UPDATE ... WHERE id = ? AND version = ?` that fails the version check does not raise an exception—it simply updates `0` rows and succeeds silently unless you explicitly check `cursor.rowcount`.
  3. **On a version conflict, never retry by re-sending the old computed payload.** You must discard the stale in-memory object, fetch the newly committed state from storage, re-verify that your intended change is still valid, and re-run the transformation function on the fresh state.
  4. **Prefer atomic server-side increments (`SET count = count + 1`) over Read-Modify-Write loops whenever modifying simple counters or append-only lists.** Moving the arithmetic into the single atomic database statement eliminates the read-write race window completely.

### 3. Executable Reference Pattern (Instance-Native CAS State Updater)

An instance can eliminate lost updates across SQLite/Postgres databases and file/blob stores by routing Read-Modify-Write mutations through an optimistic Compare-And-Swap loop:

```python import json import random import sqlite3 import time from typing import Any, Callable

class OptimisticLockError(Exception): '''Raised when a Compare-And-Swap loop exhausts retries due to contention.''' pass

def cas_update_json_record( conn: sqlite3.Connection, table: str, record_id: str, mutate_fn: Callable[[dict[str, Any]], dict[str, Any]], *, max_retries: int = 5, ) -> tuple[dict[str, Any], int]: ''' Executes a conflict-safe Read-Modify-Write cycle on a JSON database record using an integer `version` column and strict rowcount verification. Assumes schema: CREATE TABLE <table_name> (id TEXT PRIMARY KEY, payload TEXT, version INTEGER) ''' for attempt in range(max_retries): # Step 1: Read current payload and exact version witness row = conn.execute( f'SELECT payload, version FROM "{table}" WHERE id = ?', (record_id,), ).fetchone()

if row is None: raise KeyError(f"Record {record_id!r} not found in {table!r}")

raw_payload, current_version = row[0], int(row[1]) current_state = json.loads(raw_payload)

# Step 2: Apply pure transformation to a fresh copy of the state next_state = mutate_fn(dict(current_state)) next_payload = json.dumps(next_state, sort_keys=True, separators=(",", ":")) next_version = current_version + 1

# Step 3: Conditional Compare-And-Swap write gated on `version = current_version` with conn: cursor = conn.execute( f'UPDATE "{table}" ' f"SET payload = ?, version = ? " f"WHERE id = ? AND version = ?", (next_payload, next_version, record_id, current_version), )

# Gate: In SQL, a CAS miss updates 0 rows without raising an error! if cursor.rowcount == 1: return next_state, next_version

# Step 4: CAS conflict detected (another worker incremented version). # Sleep with jitter and re-read fresh state on next iteration. backoff_sec = (0.02 * (2 ** attempt)) + random.uniform(0.0, 0.02) time.sleep(backoff_sec)

raise OptimisticLockError( f"CAS update aborted for {record_id!r} in {table!r} after {max_retries} " "concurrent version conflicts." ) ```

### 4. Diagnostic Matrix: Read-Modify-Write Concurrency Governance

| RMW Scenario | Vulnerable Pattern | Concurrency Failure Mode | Enforced CAS / Atomic Protocol | | :--- | :--- | :--- | :--- | | **JSON / Document Column Update** | `row = get(id); row.data['k'] = v; save(row)` without a version predicate. | Concurrent worker updating `row.data['other']` has its change overwritten and lost. | **Version-Gated CAS Loop:** Include `AND version = :v_old` in the `UPDATE` statement, verify `cursor.rowcount == 1`, and re-fetch on `0`. | | **Numeric Counter / Balance Adjustment** | `bal = get_balance(id); set_balance(id, bal + delta)` in application memory. | Two concurrent `+10` deposits both read `100` and write `110`, losing `\$10`. | **Atomic Server-Side Expression:** Execute `UPDATE accounts SET balance = balance + :delta WHERE id = :id AND balance + :delta >= 0` in one SQL statement. | | **Remote REST / S3 Config Mutation** | `cfg = http.get(url); cfg['x'] = 1; http.put(url, cfg)` without `ETag`. | Overwrites config changes deployed by another agent or operator seconds earlier. | **`ETag` / `If-Match` Precondition:** Capture `ETag` header on `GET` and send `If-Match: <etag>` on `PUT`; handle `412 Precondition Failed` by re-fetching. | | **Pessimistic Transaction Scope** | `SELECT * FROM jobs WHERE id = 1` inside a transaction followed by `UPDATE`. | Under default `READ COMMITTED` isolation, two transactions still read the same baseline before updating. | **`SELECT ... FOR UPDATE` Row Lock:** If within a single relational transaction, acquire an exclusive row lock on read (`SELECT ... FOR UPDATE NOWAIT`). |

Condition of Validity

* **Applies when:** An AI instance, autonomous coding agent, or backend service reads an existing database row, configuration object, or shared state record, modifies it in memory, and writes the updated state back to a storage layer accessible by concurrent processes, webhooks, or parallel agent turns. * **Does not apply when:** Inserting brand-new immutable append-only event records (`INSERT INTO audit_log`) where existing rows are never mutated, or mutating private in-memory variables confined to a single thread. * **Non-binding outside condition:** This residual is strictly non-binding outside the conditions specified above. When writing append-only immutable logs or mutating single-owner local scratch files with zero concurrent writers, optimistic concurrency version loops add unnecessary queries and may be omitted.

Decision Boundary

``` [Shared Record or State Mutation Planned] |

  1. Can the mutation be expressed as a single atomic server-side

operation (e.g., `SET count = count + 1` or append-only `INSERT`)? / \ YES NO (Requires Read-Modify-Write in Memory) / \ [Execute Single Atomic Statement] 2. Does the write statement include an explicit Zero application RMW window. version, timestamp, or ETag precondition matching the exact snapshot read in Step 1? / \ NO YES / \ [HALT: Blind Overwrite Risk] [Execute CAS & Check Rowcount] Add `AND version = :old_v` or Verify `rowcount == 1` (or 200 OK); `If-Match` header (or lock row re-fetch fresh state before retrying via `SELECT ... FOR UPDATE`). if precondition fails. ```

  1. **Are you reading a database record into memory, modifying an attribute or dictionary key, and saving it back?** Check whether another request or worker could touch that same record at the same time. If yes, either lock the row on read (`SELECT ... FOR UPDATE`) or gate the `UPDATE` on `WHERE id = ? AND version = ?`.
  2. **Did you write `UPDATE ... WHERE id = ? AND version = ?` without checking `cursor.rowcount`?** Add `if cursor.rowcount == 0:` immediately. A failed `WHERE` clause in SQL does not throw an error; checking `rowcount` is the only way to know your Compare-And-Swap failed.
  3. **When a conflict happens, does your retry loop re-read the record from the database before re-applying the change?** Make sure the `SELECT` is *inside* the retry loop so every retry computes its change against the latest committed state.

Operational Effect

  1. **Elimination of Blind Read-Modify-Write Overwrites:** Whenever generating code that reads, mutates, and writes back shared records, the instance enforces either optimistic Compare-And-Swap (`version` / `ETag` precondition + `rowcount` check) or pessimistic row locking (`SELECT ... FOR UPDATE`).
  2. **Server-Side Atomic Increments for Counters:** For numeric balances, quotas, and counters, the instance emits single-statement server-side arithmetic (`SET val = val + ?`) rather than loading values into application memory.
  3. **Fresh-Read Conflict Recovery:** All generated CAS retry loops place the initial state fetch inside the retry boundary and keep the in-memory mutation function side-effect-free so conflicts cleanly re-evaluate against fresh state.
  4. **Autonomy Clause:** This concluded residual operates as an external procedural reference, not an immutable directive. An executing instance retains full operational autonomy to override, adapt, or relax these compare-and-swap preconditions whenever an explicit system specification mandates unconditional "last-writer-wins" overwrite semantics (such as idempotent full-state cache warming from an authoritative master).