Bug type

Crash (process/app exits or hangs)

Beta release blocker

No

Summary

Bug: Memory provider cutover to Ollama leaves production index in mixed OpenAI/Ollama vector state after live sync/reload

Summary

Switching agents.defaults.memorySearch from OpenAI embeddings to Ollama embeddings can leave the live production memory index in an inconsistent state after the provider change is loaded.

In my repro, a clean isolated Ollama index completed successfully with 768-dimensional vectors, but after copying/cutting over to the production memory path and loading the config change, openclaw memory status --deep reported:

• Provider: ollama (requested: ollama)
• Model: nomic-embed-text:latest
• Indexed: 582/582 files · 6474 chunks
• Dirty: no
• Vector dims: 1536

That is inconsistent: nomic-embed-text via Ollama produced 768-dimensional vectors in the isolated build, while 1536 dimensions matches the previous OpenAI text-embedding-3-small index.

A known-good canary search then returned no matches. Rolling back the config and SQLite index to the prior OpenAI backup restored canary search results.

This appears related to the memory provider-change / live sync / auto-reindex path, rather than the initial Ollama embedding build itself.

Environment

• OpenClaw version: 2026.5.7
• OS/runtime: Linux container, Node 24.14.0
• Install/runtime style: npm/global OpenClaw CLI inside container
• Memory engine: built-in SQLite memory search (memory-core plugin)
• Previous provider/model: openai / text-embedding-3-small / 1536 dims
• New provider/model: ollama / nomic-embed-text:latest / 768 dims
• Ollama endpoint: configured local/container Ollama provider

Configuration change

Production config was changed under:

agents.defaults.memorySearch = {
  enabled: true,
  provider: "ollama",
  model: "nomic-embed-text:latest",
  fallback: "none",
  sync: {
    embeddingBatchTimeoutSeconds: 600
  }
}

The setting location matches the docs: agents.defaults.memorySearch.

After cutover/reload, production memory reported an inconsistent state:

• Provider/model: Ollama / nomic-embed-text:latest
• Vector dims: 1536, matching previous OpenAI index rather than Ollama's 768-dim isolated index
• Dirty: no
• Canary search: no matches

Rollback to the OpenAI backup restored search.

Why this may be related to #60856 but distinct

This is adjacent to #60856 because it involves Ollama-backed memory search, gateway restart/reload, and background memory sync/indexing.

However, this is not the same symptom:

• #60856: indexing times out after 120s despite embeddings being ready.
• This issue: isolated Ollama indexing succeeds, but production provider cutover/reload leaves a mixed provider/vector-dimension state and search fails.

The fix for #60856 appears to have landed before 2026.5.7, but this provider-change/index-metadata issue still reproduces on 2026.5.7.

Steps to reproduce

Reproduction outline

1. Start from a healthy OpenAI-backed production memory index.

   Observed before cutover:

   Provider: openai (requested: openai)
   Model: text-embedding-3-small
   Indexed: 582/582 files · 6474 chunks
   Dirty: no
   Vector dims: 1536

2. Create an isolated profile/config with memory search set to Ollama.

3. Force/build the isolated Ollama memory index.

   Isolated profile completed cleanly:

   Provider: ollama (requested: ollama)
   Model: nomic-embed-text:latest
   Indexed: 582/582 files · 6474 chunks
   Dirty: no
   Embeddings: ready
   Vector dims: 768

4. Run a canary search against the isolated Ollama profile.

   Result: canary search returned relevant matches.

5. Back up production config and ~/.openclaw/memory/main.sqlite.

6. Change production config to Ollama and copy the clean isolated Ollama SQLite index into the production memory path.

7. Run production memory status/search after live reload/sync has had a chance to touch the index.

   Observed inconsistent production state:

   Provider: ollama (requested: ollama)
   Model: nomic-embed-text:latest
   Indexed: 582/582 files · 6474 chunks
   Dirty: no
   Embeddings: ready
   Vector dims: 1536

8. Run a known-good canary search.

   Result: no matches.

9. Roll back config and production SQLite to the prior OpenAI backup.

   Verification after rollback:

   Provider: openai (requested: openai)
   Model: text-embedding-3-small
   Indexed: 582/582 files · 6474 chunks
   Dirty: no
   Embeddings: ready
   Vector dims: 1536

   The same canary search returned matches again.

Expected behavior

When memorySearch.provider / model changes from OpenAI to Ollama:

• The production index should be rebuilt or replaced cleanly in the new provider's vector space.
• Provider: ollama + Model: nomic-embed-text:latest should not report stale OpenAI-sized 1536 dimensions.
• A provider/dimension mismatch should be detected and treated as dirty/invalid, not Dirty: no.
• Search should not silently return no matches because the index metadata/vector store is in a mixed state.

Actual behavior

After cutover/reload, production memory reported an inconsistent state:

• Provider/model: Ollama / nomic-embed-text:latest
• Vector dims: 1536, matching previous OpenAI index rather than Ollama's 768-dim isolated index
• Dirty: no
• Canary search: no matches

Rollback to the OpenAI backup restored search.

OpenClaw version

2026.5.7

Operating system

Docker Container on Ubuntu

Install method

docker

Model

/openrouter/openai-codex/gpt-5.5

Provider / routing chain

OpenClaw memorySearch -> Ollama embedding provider -> nomic-embed-text:latest

Additional provider/model setup details

Ollama via container OpenClaw via container

• OpenClaw version: 2026.5.7
• OS/runtime: Linux container, Node 24.14.0
• Install/runtime style: npm/global OpenClaw CLI inside container
• Memory engine: built-in SQLite memory search (memory-core plugin)
• Previous provider/model: openai / text-embedding-3-small / 1536 dims
• New provider/model: ollama / nomic-embed-text:latest / 768 dims
• Ollama endpoint: configured local/container Ollama provider

Logs, screenshots, and evidence

Isolated Ollama rebuild monitor:
[2026-05-18 08:21:41] size=211324928 procs=yes status=Provider: ollama (requested: ollama) Model: nomic-embed-text:latest|Indexed: 582/582 files · 6474 chunks Dirty: no Embeddings: ready|Vector dims: 768

Completion marker:
Ollama current rebuild completed: Provider: ollama (requested: ollama) Model: nomic-embed-text:latest|Indexed: 582/582 files · 6474 chunks Dirty: no Embeddings: ready|Vector dims: 768

Post-cutover failure observation, recorded immediately before rollback:
Production reported `Provider: ollama` but `Vector dims: 1536`; canary search returned no matches; `/home/node/.openclaw/memory/main.sqlite` had been rewritten to 288M.

Rollback verification:
Provider: openai (requested: openai) Model: text-embedding-3-small|Indexed: 582/582 files · 6474 chunks Dirty: no Embeddings: ready|Vector dims: 1536

Current verification after rollback:
Provider: openai (requested: openai) Model: text-embedding-3-small|Indexed: 582/582 files · 6476 chunks Dirty: no Embeddings: ready|Vector dims: 1536

Impact and severity

Impact

Semantic memory appears healthy according to status, but known-good recall fails. This can silently degrade agent memory after a provider cutover and is hard to detect without a canary query.

Additional information

Hypothesis

The live production memory path may be reusing, rewriting, or validating SQLite/vector metadata insufficiently when provider/model/dimensions change. Possible areas to inspect:

• provider/model/dimension identity stored in the SQLite index metadata
• dirty detection after agents.defaults.memorySearch.provider / model changes
• embedding cache keying across providers/models/dimensions
• auto-reindex/watch sync after gateway reload/restart
• handling of copied/replaced SQLite DBs with subsequent live sync

At minimum, Provider: ollama + Vector dims: 1536 + Dirty: no should probably be considered invalid when the active Ollama model returns 768-dimensional embeddings.