Execution unavailable

Identifiers

Field	Value
Type URI	https://echo.labstack.com/pro/problems/execution-unavailable
Code	execution_unavailable
HTTP status	503

HTTP status	English title
503	Service Unavailable

When it occurs

Execution could not use its store, or another error stopped it before the handler ran.

Client handling

Retry later with the same key and request, after the Retry-After delay. Do not switch to a new key: an earlier attempt under this key may exist.

Example response

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

HTTP/1.1 503 Service Unavailable
Content-Type: application/problem+json
Cache-Control: no-store
Retry-After: 1

{
  "code": "execution_unavailable",
  "operation_ref": "",
  "operation_state": "",
  "safe_new_key": false,
  "status": 503,
  "title": "Service Unavailable",
  "type": "https://echo.labstack.com/pro/problems/execution-unavailable"
}

Server correction

Restore journal storage and inspect the original key. A store outage does not prove that an earlier external send failed.

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.
• Retry-After (always): Always 1.

Notes:

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

Related behavior

See execution for operation state and replay rules. Check the provider’s records before recovery. A timeout does not prove that an effect did not occur.