Skip to content
Settings

IDEMPOTENCY_CONFLICT — duplicate request with conflicting payload

cyoda-go version 0.6.2

Not yet implemented (#91). The error code is reserved and documented here for the future contract, but no API handler currently reads the Idempotency-Key header or raises this error. Duplicate collection requests will currently pass through without detection. Tracked for implementation or removal.

IDEMPOTENCY_CONFLICT — a request with the same idempotency key was already received but its payload differs from the original.

HTTP: 409 Conflict. Retryable: no.

The idempotency key is supplied via the Idempotency-Key HTTP header on collection create and update requests. See crud for the request shape.

The server has already processed (or is currently processing) a request with the same idempotency key, but the new request’s body or parameters differ from the first one. Idempotency keys protect against duplicate submissions of identical requests; they do not allow modifying the request after the fact.

Not retryable with the same key and a different payload. A distinct operation requires a distinct idempotency key.

  • errors
  • errors.CONFLICT
  • errors.TX_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 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.