retryable

Whether the identical request could succeed later without being changed.

true says the failure is about the cluster's current state — it is rate limiting, a node is out of disk, a shard has no live replica — and waiting is a strategy. false says the request itself is the problem, and the same bytes will be refused again however long you wait.

It is a statement about the server, not about your data. Retrying a read on a retryable failure is always safe. Retrying a write is safe only where the write is idempotent: an upsert keyed by point id is, because writing the same point twice leaves the same collection; a dev.kdrant.QdrantClient.batchUpdate mixing upserts and filter-scoped deletes is not, because the delete's filter is re-evaluated against whatever the first attempt already applied.

The client already retries the retryable failures it can see, with backoff, before surfacing them. Reaching a caller means those attempts were used up.