test(knowledge/backends): ChromaDB contract coverage is stubbed out — decide how to restore it (follow-up to #13239) #13242

Context

#13239 / PR #13241 established that the BaseClient / BaseCollection and AsyncBaseClient / AsyncBaseCollection contract suites have not exercised ChromaDB since 2026-05-26.

autobot-backend/conftest.py (lines 119-131) unconditionally installs a MagicMock package stub for chromadb into sys.modules, added by 436607992 "fix(startup): chromadb hang + missing imports regression (MVA-1119)" because the real import hangs on hosts without a local Chroma server (gRPC keep-alive probes via opentelemetry) and because an opentelemetry version in some venvs raises ImportError.

Because the stub lands in sys.modules before collection, pytest.importorskip("chromadb") never skipped — so every chromadb-parametrized contract assertion ran against a MagicMock and failed (38 failures). PR #13241 makes those cases skip honestly. The in-memory parametrization still enforces the full contract on every run.

What is now uncovered

knowledge/backends/chromadb_adapter.py and knowledge/backends/async_chromadb_adapter.py are thin pass-through wrappers, so their contract behaviour is ChromaDB's behaviour and cannot be meaningfully verified without the real package. Currently unverified in CI:

• kwarg marshalling for get / query / delete (which keys are forwarded, which are omitted when None)
• exception translation to ValueError in get_collection / create_collection / delete_collection
• list_collections wrapping raw ChromaDB objects into BaseCollection (discovery(knowledge/backends): #5062 ChromaDBClient.list_collections returns raw chromadb.Collection not wrapped in ChromaDBCollection #5134)
• _chroma_safe_name normalisation in the async client (bug(llc/kb): ChromaDB 1.x rejects ':' in collection names → company creation 500 (InvalidArgumentError) #10743)

Decision needed (owner)

Options, roughly in increasing blast radius:

1. Leave as-is — accept in-memory-only contract coverage, keep the skips.
2. Add narrow unit tests for the adapters' own logic (kwarg marshalling + exception translation) against an explicit hand-written fake, keeping the stub untouched. No hang risk, recovers most of the lost signal, does not verify real ChromaDB semantics.
3. Make the global chromadb stub conditional (try the real import first, as _SIMPLE_STUBS already does) so contract tests run against real ChromaDB where importable. Recovers full signal but risks reintroducing the MVA-1119 import hang across the whole backend suite.
4. Dedicated opt-in job — a separate CI lane with the stub disabled that runs only knowledge/backends/test_base.py and test_async_base.py against real ChromaDB, with a timeout. Isolates the hang risk from the main suite at the cost of a new lane.

Option 3 in particular is a suite-wide change and should not be made without an owner call.

References

• Issue bug/test(knowledge): 38 behavioural failures across backends test_base.py and test_async_base.py — adapters may not persist collections #13239, PR fix(tests): skip chromadb contract parametrization when conftest stubs chromadb (#13239) #13241
• Stub: autobot-backend/conftest.py lines 119-131 and _make_pkg_stub lines 37-63
• Stub commit: 436607992 (MVA-1119, 2026-05-26)
• Contract tests: autobot-backend/knowledge/backends/test_base.py, test_async_base.py