Bug type

Crash (process/app exits or hangs)

Beta release blocker

No

Summary

agents.defaults.memorySearch.remote.batch.concurrency = 1 has no effect — OpenClaw sends 30+ concurrent embedding requests during indexing, causing exec sessions to be killed before any chunk is indexed.

Steps to reproduce

1. Set agents.defaults.memorySearch.remote.batch.concurrency = 1 in openclaw.json
2. Run openclaw memory index --verbose --force on a workspace with 50+ memory files
3. Observe: 30+ "batch start" messages appear within seconds, then process is SIGKILLed after ~22 minutes with 0 chunks indexed

Expected behavior

With concurrency = 1, OpenClaw should send embedding requests one at a time. Each request to Ollama with OLLAMA_MAX_LOADED_MODELS=1 takes ~44s (serialized). At 1 request at a time, a small batch should complete without timeout.

Actual behavior

Verbose output shows [memory] embeddings: batch start repeated 30+ times in rapid succession (within seconds). Exec session is SIGKILLed after ~22 minutes. No chunks are indexed. The concurrency setting appears to have no effect.

OpenClaw version

2026.4.14

Operating system

Mac OS 26.3.1

Install method

nom

Model

ollama/qwen3:4b embedding

Provider / routing chain

openclaw -> ollama (local, /v1 endpoint) -> qwen3-embedding:4b

Additional provider/model setup details

"agents": {
  "defaults": {
    "memorySearch": {
      "provider": "openai",
      "remote": {
        "baseUrl": "http://127.0.0.1:11434/v1",
        "apiKey": "ollama-local"
      },
      "model": "qwen3-embedding:4b",
      "remote": {
        "batch": {
          "enabled": true,
          "concurrency": 1
        }
      }
    }
  }
}

Provider: Ollama via OpenAI-compatible endpoint (/v1/embeddings) Embedding model: qwen3-embedding:4b (also tested with 8b — same behavior) OLLAMA_MAX_LOADED_MODELS=1 — single model at a time in VRAM OLLAMA_NUM_PARALLEL=1 — Ollama's server-side parallel cap (1) Config model: openclaw 2026.4.14 (323493f)

Logs, screenshots, and evidence

Ollama server log (/opt/homebrew/var/log/ollama.log) during openclaw memory index --verbose:

[GIN] 2026/04/14 - 16:03:22 | 400 | 15.19s | 127.0.0.1 | POST "/v1/embeddings"
[GIN] 2026/04/14 - 16:03:22 | 400 |  5.89s | 127.0.0.1 | POST "/v1/embeddings"
[GIN] 2026/04/14 - 16:03:22 | 400 | 20.98s | 127.0.0.1 | POST "/v1/embeddings"
time=... msg="aborting embedding request due to client closing the connection"

Verbose CLI output (openclaw memory index --verbose --force):

[memory] sync: indexing memory files
[memory] embeddings: batch start
[memory] embeddings: batch start
[memory] embeddings: batch start
[memory] embeddings: batch start
[memory] embeddings: batch start
[memory] embeddings: batch start
[memory] embeddings: batch start
[memory] embeddings: batch start
[memory] embeddings: batch start
... (30+ total)
Process exited with signal SIGKILL

openclaw memory status after:
Indexed: 0/51 files · 0 chunks
Dirty: yes
Batch: disabled (failures 0/2)

Impact and severity

• Affected users: Any OpenClaw user with memory indexing enabled and an Ollama backend that has OLLAMA_MAX_LOADED_MODELS=1 (common for VRAM-constrained setups — e.g., Apple Silicon Mac with multiple large models)
• Severity: Blocks workflow — memory indexing cannot complete on affected setups
• Frequency: Always — every openclaw memory index run exhibits this behavior
• Consequence: Users cannot reindex memory. The vector store becomes stale. Search quality degrades over time as new memory files go unindexed.

Additional information

• When batch.enabled = false was set (with concurrency still = 1), behavior was unchanged — batch requests still fired concurrently. This suggests the config path may not be fully wired to the batch execution layer.
• No regression period identified — this issue appears to have existed since batch concurrency config was introduced.
• Workaround: None that preserves indexing — users must accept that openclaw memory index will hang indefinitely and never complete on single-model Ollama setups.
• The 44s latency per request is not a model problem — it's queuing contention from OpenClaw's parallel requests all waiting for OLLAMA_MAX_LOADED_MODELS=1.