cyborgdb.CyborgDBError. The subclass is chosen from the HTTP status code, so callers can catch one class per failure mode.
Exception classes
All seven classes inherit from
CyborgDBError, which inherits from ValueError. Code written against earlier SDK versions that catches ValueError still catches them.
cyborgdb.ValidationError shares its name with pydantic.ValidationError. Import it as cyborgdb.ValidationError to avoid confusion.Attributes
The original exception is kept as
__cause__.
Logging
The SDK also logs every failed request atERROR level through Python’s logging module, including the response headers and body, even when the caller catches the exception. All SDK loggers sit under the cyborgdb logger, so they can be quieted together:
Retries
The SDK sets no request timeout and retries a request only once, when its connection fails or drops (see Client).retryable marks the errors that are safe to retry; any further retry loop is up to the caller:
Errors raised before a request is sent
Argument checks that run in the SDK, before anything is sent to the service, raisecyborgdb.ValidationError with status_code None. They cover:
- an
index_keythat isn’t 32 bytes, or neitherindex_keynorkms_namepassed tocreate_index() - an invalid
storage_precision - a NumPy array with the wrong number of dimensions
- mismatched
ids,vectors,metadata, orcontentslengths inupsert_binary() - an upsert item without an
id - an
order_bydict with more than one key
upsert_binary() or query_binary() expects a NumPy array, raises a ValidationError that is also a TypeError, so existing except TypeError blocks keep working.
A few wrong-type arguments are caught by the generated request models instead, and raise
pydantic.ValidationError: for example get(5), delete([1, 2]), query(top_k="abc"), query_metadata(order_by=5), or query() with neither query_vectors nor query_contents. It is still a ValueError.Other statuses
HTTP statuses outside the mapping above (for example405 or 413) raise the base CyborgDBError, with status_code set.