Error handling on SageMaker
Every Sarvam model container on SageMaker uses the same error contract. Read this once, then see the per-model references — Speech-to-Text, Text-to-Speech, and Sarvam Vision — for the model-specific bodies.
Every non-2xx is delivered as HTTP 424
Through sagemaker-runtime:InvokeEndpoint, any error the container returns is collapsed by boto3 into a ModelError (HTTP 424). The container’s real status is in OriginalStatusCode, its JSON body in OriginalMessage, and its Retry-After header is dropped — so retry hints ride in the body as retry_after.
Branch on OriginalStatusCode + error.code, never on the HTTP status (it is always 424).
Error envelope
Every error body is JSON with the same shape:
Optional fields extend it: detail_code (a specific reason), retryable (bool), and retry_after (seconds). Sarvam Vision always carries detail_code and retryable.
Overload (backpressure) sheds immediately — it does not queue
At capacity, the container rejects excess work at once rather than queueing it, using error.code = "service_overloaded" with a body retry_after:
Client rule: treat 429 or 503 with code: "service_overloaded" as “retry after retry_after seconds, with jitter.” Never retry a 400 — fix the request instead.