IDEMPOTENCY_CONFLICT — duplicate request with conflicting payload

cyoda-go version 0.8.3

errors.IDEMPOTENCY_CONFLICT

STATUS

Not yet implemented. 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.

NAME

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

SYNOPSIS

HTTP: 409 Conflict. Retryable: no.

DESCRIPTION

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.

SEE ALSO

• errors
• errors.CONFLICT
• errors.TX_CONFLICT

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 TX_CONFLICT — Reserved. Not currently emitted by any cyoda-go code path.

Raw formats

• /help/errors/idempotency_conflict.json — full descriptor (matches GET /help/{topic} envelope)
• /help/errors/idempotency_conflict.md — body only