feat(client): support with and async with on the clients

[Aryan-Pardeshi]

Closes #1285.

QdrantClient and AsyncQdrantClient own a gRPC channel, an httpx client and — in local mode — a SQLite database plus a portalocker lockfile, but neither implemented the context manager protocol. The cleanup path was the try/finally block that with exists to remove.

What's here

Sync (qdrant_client/qdrant_client.py):

with QdrantClient("localhost") as client:
    client.upsert(...)
# close() runs here, raised or not

Async (qdrant_client/async_qdrant_client.py):

async with AsyncQdrantClient("localhost") as client:
    await client.upsert(...)

Both __exit__/__aexit__ just delegate to the existing close(), which is already idempotent on both QdrantRemote (_closed = True) and QdrantLocal (_closed = True plus portalocker unlock), so a stray second close() after the block is still fine.

The generator part

async_qdrant_client.py is generated from the sync file, and the transform only converts def → async def for names present on AsyncQdrantBase. __aenter__ isn't there, so a naive transform would have emitted a sync __enter__ on the async client — which Python's async with won't accept.

So ClientGenerator now takes a rename_methods map (__enter__ → __aenter__, __exit__ → __aexit__) and ClientFunctionDefTransformer handles three things for those methods: renames them, forces them async regardless of the async_methods lookup, and remaps the string return annotation ("QdrantClient" is an ast.Constant, so NameTransformer and ClassDefTransformer both walk right past it).

I ran the generator and diffed its output against the committed async_qdrant_client.py: the context manager block comes out byte-identical, and the only other differences are pre-existing ones from my local tool versions (autoflake wasn't installed, and my ruff formats for (k, v) in without the parens).

Tests

tests/test_context_manager.py, six cases across sync and async: the happy path, an exception raised inside the block (close still runs, exception still propagates), and a redundant close() after the block to pin down the idempotence the design leans on. All use :memory:, so no server needed.

Before the change the sync tests fail with TypeError: 'QdrantClient' object does not support the context manager protocol (missed __exit__ method).

---

Replaces #1329, which was branched from master and showed as conflicting against the dev base this repo targets. Same change, clean history off dev.

[netlify]

✅ Deploy Preview for poetic-froyo-8baba7 ready!

Name	Link
🔨 Latest commit	72e8b5a
🔍 Latest deploy log	https://app.netlify.com/projects/poetic-froyo-8baba7/deploys/6a8096495f5dc70008a7c452
😎 Deploy Preview	https://deploy-preview-1347--poetic-froyo-8baba7.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 5b5c6e5e-a187-44d2-a9a0-6588ab8b3ddb

📥 Commits

Reviewing files that changed from the base of the PR and between f003e6c and 72e8b5a.

📒 Files selected for processing (5)

• qdrant_client/async_qdrant_client.py
• qdrant_client/qdrant_client.py
• tests/test_context_manager.py
• tools/async_client_generator/client_generator.py
• tools/async_client_generator/transformers/client/function_def_transformer.py

---

📝 Walkthrough

Walkthrough

QdrantClient now supports with blocks, and AsyncQdrantClient supports async with blocks. Both clients close on context exit, including after exceptions. Async client generation now renames synchronous context-manager methods and updates related return annotations. Tests cover normal exits, exception exits, and repeated closing.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Merge Risk: ⚪ Minimal · up to 72e8b

The PR adds synchronous and asynchronous context-manager support so client resources are closed automatically, including when the block raises; no actionable merge-blocking risk remains after normal checks and review.

Possibly related PRs

• qdrant/qdrant-client#1286: Implements the same context-manager support, generator changes, and tests.
• qdrant/qdrant-client#1300: Modifies the same client facades with lifecycle-related APIs.
• qdrant/qdrant-client#1329: Implements related context-manager support, generator updates, and tests.

Suggested reviewers: joein

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Linked Issues check	⚠️ Warning	The implementation meets the main context-manager objectives, but the PR adds six tests instead of the issue's required 12+12 tests and does not show remote-mode coverage.	Add the required 12 synchronous and 12 asynchronous tests, including remote-client coverage and regeneration validation.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely summarizes the added synchronous and asynchronous context-manager support.
Description check	✅ Passed	The description directly explains the context-manager implementation, generator updates, tests, and cleanup behavior.
Out of Scope Changes check	✅ Passed	The code, generator updates, and tests all support the linked issue's context-manager requirements.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}