Skip to content

Operation policy changed

FieldValue
Type URIhttps://echo.labstack.com/pro/problems/operation-policy-changed
Codeoperation_policy_changed
HTTP status409
HTTP statusEnglish title
409Conflict

The stored operation uses a different safety policy or fingerprint definition from the current configuration. Execution cannot safely compare or replay it.

Do not retry automatically, and do not switch to a new key. An operator must review the recorded operation and the configuration change.

If your application installs a custom handler, the body may differ.

HTTP/1.1 409 Conflict
Content-Type: application/problem+json
Cache-Control: no-store
{
"code": "operation_policy_changed",
"operation_ref": "AAAAAAAAAAAAAAAAAAAAAAAA",
"operation_state": "started",
"safe_new_key": false,
"status": 409,
"title": "Conflict",
"type": "https://echo.labstack.com/pro/problems/operation-policy-changed"
}

Deploy code compatible with the stored SafetyVersion and ReconcilerVersion, or recover the operation with authorization. Do not overwrite stored policies or bypass the mismatch with a new key.

  • type (string, always): The exact type URI above.
  • title (string, always): The HTTP status text.
  • status (integer, always): The HTTP status of the response.
  • code (string, always): The stable code above.
  • operation_ref (string, always): An opaque reference to the operation. It is set only after ReplayCheck allows the request, and is empty when no operation was found. Use it to look up the operation; it does not grant access.
  • operation_state (string, always): started, uncertain, completed or failed; empty when no operation was found.
  • safe_new_key (boolean, always): true only when the client may retry with a new key. It is always false when operation_ref and operation_state are empty.

Headers:

  • Cache-Control (always): no-store on every execution problem.

Notes:

  • Execution removes any Idempotent-Replayed header from problem responses.

See execution for operation state and replay rules.