Description
Codebase indexing consistently fails during the initial scan when using Qdrant (both Qdrant Cloud and local Docker qdrant/qdrant:latest) with Zoo Code 3.80. The UI shows:
Failed during initial scan: Failed to connect to Qdrant vector database. Please ensure Qdrant is running and accessible at https://<cluster>.eu-central-1-0.aws.cloud.qdrant.io. Error: Internal Server Error
The same error occurs with a local instance at http://localhost:6333 when the server image is recent.
In the VS Code Extension Host console (Help → Toggle Developer Tools → Console) the underlying warning is:
Client version 1.14.0 is incompatible with server version 1.16.3. Major versions should match and minor version difference must not exceed 1. Set checkCompatibility=false to skip version check.
This is intermittent on Qdrant Cloud free-tier (cold-start after auto-pause can also return transient 500s), but deterministic when the server is ≥1.16.0.
Reproduction Steps
- Install Zoo Code 3.80 (or current
main as of 2026-08-22).
- Configure codebase indexing:
- Cloud: Create a free cluster at https://cloud.qdrant.io, copy URL like
https://<cluster>.eu-central-1-0.aws.cloud.qdrant.io and API key into Zoo Code settings (codebaseIndexQdrantUrl / codeIndexQdrantApiKey).
- Local:
docker run -p 6333:6333 qdrant/qdrant:latest (currently 1.16.x) and set URL to http://localhost:6333.
- Enable codebase indexing and trigger an initial scan (open a workspace, or reload window).
- Observe status icon → Error, and the message above. Check Developer Tools console for the
Client version ... is incompatible warning.
Expected vs Actual
- Expected: Indexing connects to Qdrant, creates collection if needed, and indexes blocks.
- Actual: Initial scan fails immediately with
Internal Server Error wrapped as qdrantConnectionFailed → failedDuringInitialScan. No blocks indexed. Retrying sometimes succeeds after reload (orchestrator preserves cache when indexingStarted is false), but fails again on next full scan.
Root Cause Analysis
The Qdrant JS client enforces minor version difference ≤ 1. Zoo Code still depends on @qdrant/js-client-rest@^1.14.0 without checkCompatibility:false, so any server ≥1.16.0 (including Qdrant Cloud, which always runs latest) is rejected client-side. The client throws a generic Internal Server Error which the extension surfaces as a connection failure.
Evidence on main (2026-08-25):
src/package.json:469: "@qdrant/js-client-rest": "^1.14.0"src/services/code-index/vector-store/qdrant-client.ts:58,71: both new QdrantClient({...}) calls lack checkCompatibility: false (verified via grep -n checkCompatibility → 0 hits; only User-Agent: Zoo-Code differs from upstream)pnpm-lock.yaml: specifier: ^1.14.0 resolves to 1.18.0 (so bump is non-breaking, but version check is still enabled)- i18n keys:
src/i18n/locales/en/embeddings.json:32 (qdrantConnectionFailed) and :70 (failedDuringInitialScan) → src/services/code-index/vector-store/qdrant-client.ts:212 → src/services/code-index/orchestrator.ts:326
This is the same bug reported upstream:
Zoo Code 3.80 release notes (2026-08-22) list no Qdrant fix; git log --follow -- src/services/code-index/vector-store/qdrant-client.ts shows no qdrant-related commits since the fork.
Proposed Fix
Port Roo Code PR #11886 to Zoo Code:
- Bump
@qdrant/js-client-rest from ^1.14.0 to ^1.18.0 (or at least ^1.17.0) in src/package.json.
- Set
checkCompatibility: false in both QdrantClient constructor sites in src/services/code-index/vector-store/qdrant-client.ts (around lines 58 and 71).
Example:
new QdrantClient({
url: qdrantUrl,
apiKey: qdrantApiKey,
checkCompatibility: false,
})Reference implementation: https://github.com/RooCodeInc/Roo-Code/pull/11886/files
Risk Assessment
Low risk. checkCompatibility:false only disables the client-side version probe; the REST API is backward-compatible. The PR's 66 tests in qdrant-client.spec.ts passed. The alternative (keeping the check) guarantees breakage for every user on Qdrant Cloud or latest Docker. No security or data-loss implications.
Workarounds (until fixed)
- Disable indexing if not needed: Settings → Codebase Indexing → toggle off (
codebaseIndexEnabled: false). The codebase_search tool becomes unavailable but the error disappears.
- Pin local Qdrant to a compatible server:
docker run -d --name qdrant --restart unless-stopped -p 6333:6333 -v qdrant_data:/qdrant/storage qdrant/qdrant:v1.13.6 (per #11885, v1.13.6 is compatible with client 1.14.0).
- Cloud users: Cloud version cannot be pinned; retry after 30s or reload window (cold-start transient). If persistent, switch to local pinned Qdrant or disable indexing until the fix ships.
- Verify: Check Developer Tools console for
Client version X is incompatible... to confirm this bug vs. a genuine network/auth issue (Cloud without API key returns 401/403, not 500).
Environment
- Zoo Code 3.80 (2026-08-22) and current
main (2026-08-25)
- Qdrant Cloud (any region, e.g.
eu-central-1-0.aws.cloud.qdrant.io, server v1.16.3+) or local qdrant/qdrant:latest
- Any embedder provider (OpenAI, OpenAI-compatible, Gemini, etc.) — failure is before embedding
Additional Context
Intermittency is expected: Qdrant Cloud free-tier auto-pauses after inactivity and can return transient 500s on wake-up, and different code paths (getCollectionInfo vs createCollection) trigger the version check differently. The orchestrator preserves cache when indexing never started (orchestrator.ts:310-330), so a failed launch may succeed on next reload via incremental scan.
Related Zoo Code issues: #340 (400 PUT), #773 (Invalid API endpoint), #870 (request for LanceDB alternative) — none cover this exact version incompatibility.
Thanks for maintaining Zoo Code!
Description
Codebase indexing consistently fails during the initial scan when using Qdrant (both Qdrant Cloud and local Docker
qdrant/qdrant:latest) with Zoo Code 3.80. The UI shows:The same error occurs with a local instance at
http://localhost:6333when the server image is recent.In the VS Code Extension Host console (Help → Toggle Developer Tools → Console) the underlying warning is:
This is intermittent on Qdrant Cloud free-tier (cold-start after auto-pause can also return transient 500s), but deterministic when the server is ≥1.16.0.
Reproduction Steps
mainas of 2026-08-22).https://<cluster>.eu-central-1-0.aws.cloud.qdrant.ioand API key into Zoo Code settings (codebaseIndexQdrantUrl/codeIndexQdrantApiKey).docker run -p 6333:6333 qdrant/qdrant:latest(currently 1.16.x) and set URL tohttp://localhost:6333.Client version ... is incompatiblewarning.Expected vs Actual
Internal Server Errorwrapped asqdrantConnectionFailed→failedDuringInitialScan. No blocks indexed. Retrying sometimes succeeds after reload (orchestrator preserves cache whenindexingStartedis false), but fails again on next full scan.Root Cause Analysis
The Qdrant JS client enforces
minor version difference ≤ 1. Zoo Code still depends on@qdrant/js-client-rest@^1.14.0withoutcheckCompatibility:false, so any server ≥1.16.0 (including Qdrant Cloud, which always runs latest) is rejected client-side. The client throws a genericInternal Server Errorwhich the extension surfaces as a connection failure.Evidence on
main(2026-08-25):src/package.json:469:"@qdrant/js-client-rest": "^1.14.0"src/services/code-index/vector-store/qdrant-client.ts:58,71: bothnew QdrantClient({...})calls lackcheckCompatibility: false(verified viagrep -n checkCompatibility→ 0 hits; onlyUser-Agent: Zoo-Codediffers from upstream)pnpm-lock.yaml:specifier: ^1.14.0resolves to1.18.0(so bump is non-breaking, but version check is still enabled)src/i18n/locales/en/embeddings.json:32(qdrantConnectionFailed) and:70(failedDuringInitialScan) →src/services/code-index/vector-store/qdrant-client.ts:212→src/services/code-index/orchestrator.ts:326This is the same bug reported upstream:
[BUG] Qdrant client v1.14.0 incompatibility with Qdrant server v1.16.3 causes "Internal Server Error" in Roo Code 3.51.0(2026-03-07)fix: bump qdrant client to v1.17.0 and disable version compatibility check(never merged in RooCodeInc, not ported to Zoo Code)Zoo Code 3.80 release notes (2026-08-22) list no Qdrant fix;
git log --follow -- src/services/code-index/vector-store/qdrant-client.tsshows no qdrant-related commits since the fork.Proposed Fix
Port Roo Code PR #11886 to Zoo Code:
@qdrant/js-client-restfrom^1.14.0to^1.18.0(or at least^1.17.0) insrc/package.json.checkCompatibility: falsein bothQdrantClientconstructor sites insrc/services/code-index/vector-store/qdrant-client.ts(around lines 58 and 71).Example:
Reference implementation: https://github.com/RooCodeInc/Roo-Code/pull/11886/files
Risk Assessment
Low risk.
checkCompatibility:falseonly disables the client-side version probe; the REST API is backward-compatible. The PR's 66 tests inqdrant-client.spec.tspassed. The alternative (keeping the check) guarantees breakage for every user on Qdrant Cloud orlatestDocker. No security or data-loss implications.Workarounds (until fixed)
codebaseIndexEnabled: false). Thecodebase_searchtool becomes unavailable but the error disappears.docker run -d --name qdrant --restart unless-stopped -p 6333:6333 -v qdrant_data:/qdrant/storage qdrant/qdrant:v1.13.6(per #11885,v1.13.6is compatible with client 1.14.0).Client version X is incompatible...to confirm this bug vs. a genuine network/auth issue (Cloud without API key returns 401/403, not 500).Environment
main(2026-08-25)eu-central-1-0.aws.cloud.qdrant.io, server v1.16.3+) or localqdrant/qdrant:latestAdditional Context
Intermittency is expected: Qdrant Cloud free-tier auto-pauses after inactivity and can return transient 500s on wake-up, and different code paths (
getCollectionInfovscreateCollection) trigger the version check differently. The orchestrator preserves cache when indexing never started (orchestrator.ts:310-330), so a failed launch may succeed on next reload via incremental scan.Related Zoo Code issues: #340 (400 PUT), #773 (Invalid API endpoint), #870 (request for LanceDB alternative) — none cover this exact version incompatibility.
Thanks for maintaining Zoo Code!