Skip to content
Cyoda Documentation
Settings

CONFLICT — optimistic concurrency conflict

cyoda-go version 0.6.2

errors.CONFLICT

Section titled “errors.CONFLICT”

NAME

Section titled “NAME”

CONFLICT — an optimistic concurrency check failed because the entity was modified concurrently.

SYNOPSIS

Section titled “SYNOPSIS”

HTTP: 409 Conflict. Retryable: yes.

DESCRIPTION

Section titled “DESCRIPTION”

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.

Retryable. The full read-modify-write cycle must be repeated using the current entity state; replaying the original write without re-fetching produces stale data.

SEE ALSO

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

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 TX_CONFLICT — 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.
  • 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.
  • 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.

Raw formats

Section titled “Raw formats”