Skip to main content
Exceptions raised by the ServiceClient, TrainingClient, and SamplingClient when a server operation fails.
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 sample() response didn’t complete before the read timeout you set on the sampling client. A timeout doesn’t establish whether the sampler is still generating, finished but lost its response, or failed. The SDK doesn’t retry automatically because that could duplicate paid generation. Check server-side logs before raising the timeout you passed to ServiceClient.create_sampling_client (or the sampler_timeout you passed to create_lora_training_client) or lowering max_tokens. Sampling is unbounded by default, so you only see this when you set a timeout yourself. 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.