Skip to content
Settings

TX_CONFLICT — transaction-level conflict

cyoda-go version 0.8.3

TX_CONFLICT — the operation was aborted because of a transaction-level conflict.

HTTP: 409 Conflict. Retryable: yes.

Reserved. Not currently emitted by any cyoda-go code path.

Storage-layer serialization failures (e.g., PostgreSQL 40001/40P01) surface as CONFLICT (not TX_CONFLICT) in the current implementation. TX_CONFLICT is reserved to distinguish a future transaction-level conflict signal from the existing entity-level CONFLICT code — for example, a conflict detected at the transaction boundary rather than at an individual entity write.

Retryable. The full transaction — including any reads performed inside it — must be restarted from the beginning.

  • errors
  • errors.CONFLICT
  • errors.EPOCH_MISMATCH
  • errors.IDEMPOTENCY_CONFLICT
  • cyoda help errors — Every error response from the Cyoda REST API carries a structured errorCode in the properties object. Multiple codes may share the same HTTP status. Programmatic handling keys on errorCode, not HTTP status.
  • cyoda help errors CONFLICT — The server detected that the entity was modified by another writer between the time it was read and the time the current write was committed. Normal outcome under concurrent load.
  • cyoda help errors EPOCH_MISMATCH — Shard ownership is tracked by an epoch counter that increments whenever the cluster re-partitions. A write is rejected with this error when the writing node’s cached epoch is stale — another node has since taken ownership of the shard. This prevents split-brain writes.
  • cyoda help errors IDEMPOTENCY_CONFLICT — The idempotency key is supplied via the Idempotency-Key HTTP header on collection create and update requests. See crud for the request shape.