Timeout configuration too aggressive when using Ollama for codebase index embedding

[danntee]

App Version

3.23.11

API Provider

Ollama

Model Used

nomic-embed-code

Roo Code Task Links (Optional)

No response

🔁 Steps to Reproduce

1. Setup (OS, extension version, settings)

• Operating System: Windows 11
• Roo Code Version: 3.23.11
• Ollama Version: 0.9.6
• Ollama Model: nomic-embed-code
• Configuration Settings:

  {
    "embedding": {
      "provider": "ollama",
      "model": "nomic-embed-code",
      "baseUrl": "http://localhost:11434"
    }
  }

2. Exact actions (clicks, input, files, commands)

Start Ollama service

ollama serve

Pull and run the embedding model

ollama pull nomic-embed-code

Open Roo Code client

• Configure Ollama as embedding provider

Go to Settings → Embedding Provider

• Select "Ollama"
• Set model name: nomic-embed-code
• Set URL: http://localhost:11434

Attempt to index the codebase

• Open project folder
• Click "Start Indexing" or execute indexing command

2. What happened after each step

• ✅ Ollama service started successfully, port 11434 accessible
• ✅ Embedding model downloaded and running normally
• ✅ Roo Code client started normally
• ✅ Ollama provider configuration saved successfully
• ❌ Issue occurred:
  • Indexing started, needed to process 1629 code blocks
  • Successfully indexed 909 code blocks, then problems began
  • Roo Code Error Message:

    Error - Failed during initial scan: Indexing partially failed: Only 909 of 1629 blocks were indexed. Batch processing failed after 3 attempts: Failed to connect to embedder service. Please check your connection settings and ensure the service is running.

  • Ollama Server Logs (Time: 2025-07-15T16:51:07.228+08:00):

    level=INFO source=server.go:907 msg="aborting embedding request due to client closing the connection"
    

    This error message appeared multiple times.

3. Behavior Analysis

Expected Behavior

• Indexing should complete all 1629 code blocks successfully.
• The client should wait for Ollama to complete each embedding request.

Actual Behavior

• The client starts timing out when processing reaches 909/1629 code blocks.
• The connection is actively closed by the client, causing Ollama to abort ongoing requests.
• Complete failure after 3 retry attempts.

4. Suggestions

• Add a configurable timeout setting for the embedding provider. This would allow users to increase the timeout duration for models or hardware that require more time to process embedding requests, preventing the client from prematurely closing the connection.

💥 Outcome Summary

Expected codebase indexing to complete successfully, but Roo Code client timed out and closed connections prematurely, causing Ollama to abort embedding requests mid-process.

📄 Relevant Logs or Errors (Optional)

[roomote]

I am working on fixing this timeout issue with Ollama embedding. The problem appears to be that the client is timing out and closing connections prematurely during codebase indexing, causing Ollama to abort embedding requests. I will investigate the timeout configuration and implement a solution to make it configurable for slower embedding providers like Ollama.

[daniel-lxs]

Hey, I took a look at this timeout issue with Ollama and found the root cause.

The problem is in src/services/code-index/embedders/ollama.ts where there are hardcoded timeout values that are too aggressive for local Ollama instances:

• Line 64: 10-second timeout for embedding requests
• Line 142: 5-second timeout for validation requests
• Line 200: 5-second timeout for test embedding

When processing large codebases (like the 1629 code blocks mentioned), these timeouts cause the client to abort the connection prematurely, which is why you're seeing the "aborting embedding request due to client closing the connection" errors in the Ollama logs.

The fix is pretty straightforward - we just need to increase these timeout values to something more reasonable like 60 seconds. This would give Ollama enough time to process embeddings even on slower hardware or with larger models.

[danntee]

@daniel-lxs Understood.but would it be better to provide customizable timeout feature?
ps,I'd be happy to participate in improving this feature.