Database MCP

MCP stale-row conflict detection

The demo moment: the business state changed after the agent saw it, so Synapsor refused to commit.

Overview

A proposal records the row version or row hash that existed when the model requested the change. The runner later includes that expected version in the guarded writeback predicate.

If the row changed after the proposal was created, affected_rows is zero. The runner treats that as conflict, records a terminal receipt, and leaves the source database unchanged.

This is a database-state guarantee, not an MCP annotation hint. The model can request a stale change, but the trusted runner refuses to commit it.

Developer notes

Configure an updated_at/version column or explicit row-hash guard.
Treat affected_rows = 0 as conflict.
Treat affected_rows > 1 as a safety failure.
Show conflict as a successful safety outcome, not a silent retry loop.

Guarded update shape

conflict.sql

UPDATE invoices
SET late_fee_cents = ?, waiver_reason = ?, updated_at = CURRENT_TIMESTAMP
WHERE id = ?
  AND tenant_id = ?
  AND updated_at = ?; -- expected version from the proposal

Examples

json

{
  "schema_version": "synapsor.execution-receipt.v1",
  "status": "conflict",
  "rows_affected": 0,
  "safe_error_code": "VERSION_CONFLICT",
  "source_database_mutated": false
}