Codebase Indexing: TypeError: fetch failed during Qdrant connection despite successful external connectivity

[fev4]

App Version

3.18.5 (582a117)

API Provider

OpenAI

Model Used

text-embedding-3-small

🔁 Steps to Reproduce

1. Setup

VSCode:
Version: 1.101.0-insider (system setup)
Commit: b4912823f452c08e81283d8fd8dd9e758a00f5f4
Date: 2025-05-28T05:45:00.228Z
Electron: 35.4.0
ElectronBuildId: 11602177
Chromium: 134.0.6998.205
Node.js: 22.15.0
V8: 13.4.114.21-electron.0
OS: Windows_NT x64 10.0.22635

Qdrant Deployment: Qdrant is deployed using the official qdrant/qdrant:latest Docker image (from Docker Hub) via Coolify, which handles container orchestration and uses Traefik as a reverse proxy for external access.

Roo Code Settings:
"Enable Codebase Indexing" is enabled.
Qdrant URL: https://[YOUR_QDRANT_DOMAIN] (e.g., https://qdrant.example.com)
Qdrant API Key: [YOUR_QDRANT_API_KEY_VALUE]
Embedding Provider: OpenAI
OpenAI Model: text-embedding-3-small

2. Exact Actions
   After configuring and saving the settings, the extension attempts to initialize the codebase indexing.

3. What happened after each step
   Immediately upon attempting to start indexing, the VS Code Dev Tool panel (specifically "Roo Code" and "Log (Extension Host)") displays a series of TypeError: fetch failed errors related to Qdrant collection initialization and cleanup.

💥 Outcome Summary

Expected indexing to start but got an error instead in the dev console.

📄 Relevant Logs or Errors (Optional)

console.ts:137 [Extension Host] [QdrantVectorStore] Warning during getCollectionInfo for "ws-f5009f6ef98f9736". Collection may not exist or another error occurred: fetch failed
[Extension Host] [QdrantVectorStore] Failed to initialize Qdrant collection "ws-f5009f6ef98f9736": fetch failed
[QdrantVectorStore] Failed to initialize Qdrant collection "ws-f5009f6ef98f9736": fetch failed
[Extension Host] [CodeIndexOrchestrator] Error during indexing: TypeError: fetch failed
    at node:internal/deps/undici/undici:13510:13
    at processTicksAndRejections (node:internal/process/task_queues:105:5)
    at runNextTicks (node:internal/process/task_queues:69:3)
    at listOnTimeout (node:internal/timers:549:9)
    at processTimers (node:internal/timers:523:7)
    at AJ.globalThis.fetch

[dosubot]

Based on the available documentation, the "TypeError: fetch failed" during Qdrant connection in Roo Code typically points to a network or configuration issue between the extension and your Qdrant deployment. The documentation confirms that Qdrant must be accessible at the URL you provide, and that the API key (if used) must be correct, but it does not provide specific troubleshooting steps for this error or for setups involving Docker and Traefik as a reverse proxy [source].

Here are the most relevant checks and suggestions based on what is documented:

• Double-check that the Qdrant URL in Roo Code settings matches the externally accessible endpoint (including protocol, e.g., https://).
• Ensure that Traefik is correctly forwarding requests to Qdrant’s port (default 6333) and that any authentication headers (API key) are preserved.
• Confirm that the Qdrant API is reachable from your machine (try accessing https://[YOUR_QDRANT_DOMAIN]/collections in a browser or with curl).
• Make sure the API key is valid and has the necessary permissions.
• If you are using a self-signed certificate or custom SSL setup with Traefik, ensure that VS Code/Electron trusts the certificate, as fetch failures can occur due to SSL errors.
• The documentation also suggests verifying the base URL and API accessibility for connection errors in general [source].

The Roo Code documentation does not currently include specific troubleshooting steps for connectivity issues with Docker and Traefik or for this particular error. If the above checks do not resolve the issue, you may need to review your Traefik configuration or consult Qdrant’s own documentation/community for reverse proxy best practices.

If you have already confirmed external connectivity (e.g., via browser or curl), the problem may be with how the extension or Node.js runtime handles HTTPS, headers, or proxying in your environment. There are no known issues or recent updates in the Roo Code docs that address this error directly.

To reply, just mention my name @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[fev4]

@dosu

Confirm that the Qdrant API is reachable from your machine (try accessing https://[YOUR_QDRANT_DOMAIN]/collections in a browser or with curl).

curl -v -H "api-key: [YOUR_QDRANT_API_KEY_VALUE]" https://[YOUR_QDRANT_DOMAIN]/collections

result was:

* Host [YOUR_QDRANT_DOMAIN]:443 was resolved.
* IPv6: 2606:4700:3035::ac43:cb86, 2606:4700:3030::6815:554c
* IPv4: 104.21.85.76, 172.67.203.134
*   Trying 104.21.85.76:443...
* Connected to [YOUR_QDRANT_DOMAIN] (104.21.85.76) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=feva.dev
*  start date: May 26 00:34:29 2025 GMT
*  expire date: Aug 24 01:32:52 2025 GMT
*  subjectAltName: host "[YOUR_QDRANT_DOMAIN]" matched cert's "*.feva.dev"
*  issuer: C=US; O=Google Trust Services; CN=WE1
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA256
*   Certificate level 1: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://[YOUR_QDRANT_DOMAIN]/collections
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: [YOUR_QDRANT_DOMAIN]]
* [HTTP/2] [1] [:path: /collections]
* [HTTP/2] [1] [user-agent: curl/8.5.0]
* [HTTP/2] [1] [accept: */*]
* [HTTP/2] [1] [api-key: [YOUR_QDRANT_API_KEY_VALUE]]
> GET /collections HTTP/2
> Host: [YOUR_QDRANT_DOMAIN]
> User-Agent: curl/8.5.0
> Accept: */*
> api-key: [YOUR_QDRANT_API_KEY_VALUE]
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 200
< date: Wed, 28 May 2025 23:19:16 GMT
< content-type: application/json
< report-to: {"group":"cf-nel","max_age":604800,"endpoints":[{"url":"https://a.nel.cloudflare.com/report/v4?s=UUF%2Bcjyp6AoqEv72VQ9yVTYnq3kGTDegf1hJJ5Tmz9tDbM63sTKTm4oN17P9%2BOFJ21ogl6oSv9ArHGofTpuUeJ%2F76%2BFi5JSrKAiytMpWMw%3D%3D"}]}
< vary: Accept-Encoding
< vary: accept-encoding, Origin, Access-Control-Request-Method, Access-Control-Request-Headers
< cf-cache-status: DYNAMIC
< nel: {"report_to":"cf-nel","success_fraction":0.0,"max_age":604800}
< server: cloudflare
< cf-ray: 947179d7be464adf-MIA
< alt-svc: h3=":443"; ma=86400
<
* Connection #0 to host [YOUR_QDRANT_DOMAIN] left intact
{"result":{"collections":[]},"status":"ok","time":6.27e-6}%

this confirms the qdrant server works, the api key works (and using the correct protocol)

[dosubot]

Your curl test confirms that the Qdrant server is externally reachable, the API key is valid, and SSL is working as expected. However, Roo Code’s codebase indexing still fails with a TypeError: fetch failed during Qdrant collection initialization.

Based on the available documentation, there are no specific troubleshooting steps for this error or for setups involving Docker and Traefik as a reverse proxy. The docs only confirm that Qdrant must be accessible at the URL you provide, and that the API key (if used) must be correct, but do not address this scenario directly [source].

Given your setup and the fact that curl works but Roo Code does not, the issue is likely related to how the extension (running in VS Code/Electron/Node.js) handles HTTPS requests, headers, or proxying. Here are the most actionable next steps:

• Double-check that Traefik is forwarding all headers (especially api-key) and not stripping or altering them for requests coming from VS Code.
• Ensure there are no IP allowlist/firewall rules that might block requests from your local VS Code/Electron environment but not from curl.
• If you use a custom SSL setup, make sure the Windows/Electron/Node.js trust store includes your CA. Sometimes curl trusts a cert that Node.js/Electron does not.
• Try running VS Code with the --ignore-certificate-errors flag (for testing only) to rule out certificate trust issues.
• Check if Traefik is rewriting or redirecting requests in a way that curl handles but Node.js fetch does not (e.g., HTTP/2 vs HTTP/1.1, or path rewrites).
• If possible, enable debug logging in Traefik and Qdrant to see if the failed requests from Roo Code are reaching Qdrant at all, and if so, what is different about them.

The Roo Code documentation does not currently provide further guidance on this error or on reverse proxy setups with Traefik and Docker. If the above steps do not resolve the issue, you may need to review your Traefik configuration or consult Qdrant’s own documentation/community for reverse proxy best practices.

To reply, just mention my name @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[hannesrudolph]

Have you tried it without insider?

[git-git-hurrah]

This might be related. I'm running VS Code with Roo in a devcontainer in docker.

I get access via curl for qdrant and ollama by using host.docker.internal, but Roo gives me Error - Failed during initial scan: fetch failed.

[git-git-hurrah]

Works now since v3.19.0

[fev4]

I haven't been able to make it work, even in v3.19.0

My setup is VSCode is connected to a WSL2 environment

I'll test in stable VSCode (without insiders)

[hannesrudolph]

I haven't been able to make it work, even in v3.19.0

My setup is VSCode is connected to a WSL2 environment

I'll test in stable VSCode (without insiders)

Have you had a chance to test without insiders?