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

upstream_truncated

Provider returned truncated non-JSON 2xx; avoids double-billing on retry.

What it means

The provider answered 2xx with a body that does not parse as JSON — a gzip stream or an EOF-framed body cut short between the provider's origin and ACE, which the HTTP client decodes without error. It is never relayed as the 200 it arrived with. Typed because its remedy differs from every other 502: the provider generated and billed this turn once, so a retry pays for the answer twice. On the relays only (/v1/messages, and every surface relaying a pass-through vendor key); the engine's routed path already falls forward on the same failure.

How to recognise it

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

{
  "error": {
    "message": "...",
    "type": "upstream_truncated",
    "code": 502
  }
}

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.