Idempotency request invalid

Identifiers

Field	Value
Type URI	https://echo.labstack.com/pro/problems/idempotency-request-invalid
Code	idempotency_request_invalid
HTTP status	400, 413

HTTP status	English title
400	Bad Request
413	Request Entity Too Large

When it occurs

Execution could not fingerprint the request, so it did not record it under the key. Status 413 means the body exceeds MaxFingerprintBytes (default 1 MiB). Other fingerprinting failures return 400. Causes include malformed input, unreadable bodies, cancellation and custom fingerprint callback failures. Nothing was recorded, and the handler did not run.

Client handling

For 413, send a smaller body. For 400, check that the request is well formed before retrying. An interrupted body read can also cause this response. You can keep the same key, because nothing was recorded.

Example response

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

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
Cache-Control: no-store

{
  "code": "idempotency_request_invalid",
  "operation_ref": "",
  "operation_state": "",
  "safe_new_key": false,
  "status": 400,
  "title": "Bad Request",
  "type": "https://echo.labstack.com/pro/problems/idempotency-request-invalid"
}

HTTP/1.1 413 Request Entity Too Large
Content-Type: application/problem+json
Cache-Control: no-store

{
  "code": "idempotency_request_invalid",
  "operation_ref": "",
  "operation_state": "",
  "safe_new_key": false,
  "status": 413,
  "title": "Request Entity Too Large",
  "type": "https://echo.labstack.com/pro/problems/idempotency-request-invalid"
}

Server correction

Check fingerprint callback errors in server diagnostics. Set MaxFingerprintBytes for the operation’s body limit.

Response fields

Execution middleware

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

Related behavior

See execution for operation state and replay rules.