ACEFLEET
ace-sidecar on GitHub
all docs
/ errors · HTTP 504

gateway_timeout

Request deadline exceeded (ACE_REQUEST_DEADLINE_S); safe to retry.

What it means

The request deadline: the handler had not started its response ACE_REQUEST_DEADLINE_S (default 600s) after the transport accepted the request, and the gateway cancelled it and answered in its place. Nothing had been sent, so a retry is safe. The body wears the surface's envelope (api_error on the Anthropic surfaces, DEADLINE_EXCEEDED on Gemini, ModelTimeoutException on Bedrock), and x-ace-stage-durations beside it names the stages that completed and the one still running — byok_store=30000 is the store, upstream=… is the vendor. Once the status line has left no header can change, so a stream silent for ACE_STREAM_IDLE_S (default 300s) or open past ACE_STREAM_DEADLINE_S (default 3600s) is closed with one terminal error event carrying "type": "gateway_timeout" instead.

How to recognise it

The gateway answers HTTP 504 with x-ace-error: gateway_timeout on the response, and a body in the shared error envelope:

{
  "error": {
    "message": "...",
    "type": "gateway_timeout",
    "code": 504
  }
}

On a vendor-shaped surface (/anthropic/…, /gemini/…, /bedrock/…) the body wears that vendor's error envelope instead; the x-ace-error header is the same everywhere.

Is it ACE or the provider?

x-ace-error is present only on errors ACE originated. A vendor error relayed from upstream — a real provider 429, a provider 401 for a bad pass-through key — carries no x-ace-error, and its own type and code mean what the provider says. Read the header before deciding whether to retry, re-mint a key or surface the error.

Other 504 errors

  • store_timeout: Durable storage or BYOK store read timed out (retry with Retry-After: 5).