The server reports that an async operation failed. The
error_class attribute carries the server-side exception class name (for example, "ValueError" or "DispatcherError"), which is useful for routing in caller code.The server returned 404 for an operation ID. This can mean the server has no record of the operation (after a pod restart, for example) or that the result was TTL-evicted. Resubmit the operation if the work is still needed; the server’s idempotency-key deduplication prevents double-execution.
The server is shutting down (503 response). Retry the request against a different replica.
A single
sample() call ran past the read timeout you set on the sampling client. The request reached the sampler and the GPU was still generating when the client stopped waiting, so this is a client-side deadline rather than a sampler failure. The SDK doesn’t retry it, because the retry would restart the same generation and hit the same deadline. Sampling is unbounded by default, so you only see this when you set a timeout yourself: raise the timeout you passed to ServiceClient.create_sampling_client (or the sampler_timeout you passed to create_lora_training_client), or lower max_tokens. A subclass of TimeoutError.The sampler’s deployment entered a terminal-failure state (for example,
DEPLOY_FAILED) and will not become ready. Raised by ensure_ready and by the first sample() call on a Baseten-hosted sampler. A subclass of RuntimeError, kept distinct from transient sampling failures so callers can tell “this sample failed, retry or score it” from “the sampler is gone, abort the run”. Eval loops that catch broad exceptions per sample should re-raise this one rather than recording a zero reward.