Transactions & retries

An ordered, atomic batch

An execute request contains requestId and operations. Operations observe earlier staged changes in the same request. Schema, revision, uniqueness and object-link validation apply before the database publishes the complete candidate. A rejected transaction publishes none of its changes.

{
  "requestId": "project-title-v1",
  "operations": [
    {
      "op": "query",
      "qql": "UPDATE projects SET title = :title WHERE _key = :key AND _revision = :revision",
      "bindings": {
        "title": "Ready for review",
        "key": "first-project",
        "revision": "use-current-record-revision"
      },
      "expectedCount": 1
    }
  ]
}

Keep the exact intent

Successful mutations store their request identity and response in a durable receipt. An identical retry returns that receipt, even after restart. Reusing the identity with different operations is a conflict. A rejected write does not consume its request identity.

A timeout, interrupted connection or outcome_unknown response can leave commitment uncertain. Keep the original request and resolve it after recovery. The TS client submits once and never silently replaces the ID. Embedded callers must drop all handles and reopen after outcome_unknown.

Check the change you intend

Typed replace and delete require the current opaque revision. QQL expectedCount is a precondition: a mismatch rejects the entire request. UPDATE and DELETE count affected rows; SELECT counts returned rows after LIMIT. LIMIT 1 checks existence and cannot establish uniqueness.

Current admission limits

These are admission limits, not a complete process-memory budget. Receipt retirement, public storage policies and full cold/saturation acceptance remain open.