Skip to content
Cyoda Documentation
Settings

TX_CONFLICT — transaction serialization conflict

cyoda-go version 0.6.2

errors.TX_CONFLICT

Section titled “errors.TX_CONFLICT”

NAME

Section titled “NAME”

TX_CONFLICT — the transaction was aborted because it conflicted with a concurrent transaction at the storage level.

SYNOPSIS

Section titled “SYNOPSIS”

HTTP: 409 Conflict. Retryable: yes.

DESCRIPTION

Section titled “DESCRIPTION”

The underlying storage detected a serialization failure (e.g., PostgreSQL error 40001 or 40P01) and aborted the transaction. Normal occurrence under concurrent write load when using serializable or repeatable-read isolation.

Retryable. The entire transaction — including any data read inside it — must be restarted from the beginning.

SEE ALSO

Section titled “SEE ALSO”
  • errors
  • errors.CONFLICT
  • errors.EPOCH_MISMATCH
  • errors.IDEMPOTENCY_CONFLICT

See also

Section titled “See also”
  • 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.

Raw formats

Section titled “Raw formats”