[Feature Request] Add retry with exponential backoff for failed requests

[Harshitazz]

Problem

Currently, when a request to Qdrant fails (e.g., due to network issues or timeouts), the client does not retry automatically.

This can cause instability in production pipelines, especially during large-scale data ingestion or when using Qdrant in RAG systems.

Proposed Solution

Introduce an optional retry mechanism with exponential backoff:

• Configurable number of retries (default: 3)
• Backoff strategy (e.g., exponential with jitter)
• Retry only for transient errors (timeouts, connection issues)

Example:
client = QdrantClient(
url="...",
retry_config={
"max_retries": 3,
"backoff_factor": 0.5
}
)

Why this is useful

• Improves robustness in production environments
• Reduces need for users to implement custom retry logic
• Especially useful for batch uploads and embedding pipelines

Alternatives considered

• Users implementing their own retry logic externally (less convenient and inconsistent)

Additional context

I’d be happy to work on implementing this feature if it aligns with the project direction.

[gaurav-code098]

"Hi @Harshitazz and maintainers, I’d like to take this.

I was taking a look through the pyproject.toml and noticed you keep the core dependencies incredibly lean (mostly just httpx, grpcio, pydantic, etc.).

Since QdrantClient supports both Sync/Async and REST/gRPC backends, implementing a unified retry mechanism requires some care to ensure we don't accidentally block the async event loops. I see two potential ways to tackle this:

1. The Zero-Dependency Route (Native Python)
   We write custom wrapper functions implementing exponential backoff using asyncio.sleep() for the async clients and time.sleep() for the sync clients. This keeps the pyproject.toml exactly as lean as it is right now.

2. The tenacity Route
   We introduce the tenacity library as a new dependency. It is the industry standard for retry logic and cleanly handles both sync and async functions via simple decorators, keeping the codebase much cleaner.

Do you have a strict preference for keeping third-party dependencies to a minimum, or would the team be open to adding tenacity to handle the heavy lifting? Let me know which direction you prefer and I'll get a PR drafted!