[BUG] Impossible to index the codebase, always stuck at Indexing - Indexed 0 / 2112 blocks found

[HatemMn]

Problem (one or two sentences)

Codebase indexing stays permanently frozen at "Indexed 0 / N blocks found" when using a custom Ollama embedding model (dengcao/Qwen3-Embedding-4B:Q4_K_M), despite Ollama responding correctly to direct embedding API calls and Qdrant returning a healthy status.

Context (who is affected and when)

Affects users on macOS AND Linux (PopOs) running Roo Code v3.52.1 with a local Ollama + Qdrant setup, specifically when using community-published embedding models (non-library tags) via the Ollama provider.

For info, I tried to follow the tutorial at docs page and used the free Gemini : same issues

no error is surfaced in the UI or Output panel, making the root cause impossible to diagnose without external debugging.

Reproduction steps

Reproduction steps:

1. Install RooCode

2. Install Ollama and pull dengcao/Qwen3-Embedding-4B:Q4_K_M
   

3. Start Qdrant locally via Docker with --ulimit nofile=262144:262144
   

4. In Roo Code settings → Experimental → Codebase Indexing, set provider to Ollama, model to dengcao/Qwen3-Embedding-4B:Q4_K_M, dimension to 2560, Qdrant URL to http://localhost:6333
   

5. Open any workspace and enable codebase indexing
   

6. Observe the indexing status in the UI
   

Expected result

Indexing progresses through blocks (1/N, 2/N...) and eventually completes.

Actual result

Status permanently shows "Indexing - Indexed 0 / N blocks found" with no progress, no error message in the UI, and no relevant output in the Roo Code Output panel. Both Ollama (curl http://localhost:11434/api/embeddings returns valid embeddings) and Qdrant (/healthz returns ok) are confirmed working independently.

Variations tried (optional)

• Cleared the Qdrant collection manually via DELETE /collections/{name} and re-triggered indexing — same result
  

• Used Roo Code's built-in Clear Index button — same result
  

• Full uninstall of Roo Code including globalStorage wipe and Qdrant collection deletion, then fresh reinstall and reconfiguration — same result
  

• Tried Google Gemini as embedding provider (free tier) — blocked by 429 TooManyRequests quota errors due to free tier rate limits
  

App Version

latest

API Provider (optional)

None

Model Used (optional)

No response

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote-v0]

I've analyzed this issue and here's my proposed implementation plan:

Root Cause Analysis

After tracing the indexing flow through the codebase, the core problem is that batch embedding failures are silently accumulated and only surfaced after the entire scan completes -- which can take a very long time when every batch is failing and retrying.

Here's what happens step by step:

1. The scanner parses files and reports block counts via onFileParsed (the "N" in "0/N blocks found")
2. Blocks are dispatched in batches of 60 to processBatch(), which calls embedder.createEmbeddings()
3. When embedding fails, processBatch retries 3 times with exponential backoff (500ms, 1s, 2s delay + 60s Ollama timeout per attempt = ~183s per batch)
4. After all retries fail, the error is pushed to a batchErrors array -- but no UI feedback is given
5. Only after ALL files are scanned AND all batches complete does the orchestrator check for failures and set the "Error" state

With ~2112 blocks (35+ batches), if every batch times out and retries 3x, the user could wait 30+ minutes seeing "0/N" before any error appears. The user perceives this as "permanently stuck."

Additionally, there is no output panel logging during batch failures -- errors are only sent to console.error (developer tools), not to the Roo Code Output panel.

Proposed Changes

1. Early failure detection with fast-fail on consecutive batch errors

File: src/services/code-index/orchestrator.ts

Add a consecutive failure counter. If the first N batches (e.g., 3) all fail consecutively, abort the scan early and surface the error immediately rather than attempting all remaining batches. This turns a 30+ minute silent hang into a ~10 second error message.

2. Real-time error surfacing during indexing

File: src/services/code-index/state-manager.ts

Add a method like reportBatchError(errorMessage) that updates the status message to include a warning (e.g., "Indexing -- Indexed 0 / 2112 blocks found (errors detected, retrying...)") so the user gets immediate feedback that something is wrong.

3. Output panel logging for embedding failures

File: src/services/code-index/processors/scanner.ts

Use the VS Code output channel (via the existing logging infrastructure) to log batch failures to the Roo Code Output panel, not just console.error. This gives users diagnostic information without needing developer tools.

4. Surface the specific error message clearly

File: src/services/code-index/orchestrator.ts

When the scan completes with errors and 0 blocks indexed, include the actual error detail (e.g., "Ollama embedding failed: connection timeout" or "vector dimension mismatch") in the Error state message shown in the UI, instead of generic messages.

Summary

The fix is primarily about observability and fast-fail behavior:

• Users get error feedback within seconds instead of waiting 30+ minutes
• Errors are visible in the Output panel for diagnosis
• The indexing status message reflects ongoing issues in real time
• Generic "indexing failed" messages are replaced with actionable error details

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.