PR #63632: fix: register ollama as valid memory embedding provider

• Repository: openclaw/openclaw
• Author: zozo123
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/63632

Description (problem / solution / changelog)

Summary

Fixes regression where ollama was not recognized as a valid memory embedding provider at runtime, throwing Error: Unknown memory embedding provider: ollama.

Root cause: getMemoryEmbeddingProvider() in memory-embedding-provider-runtime.ts had an early-exit guard that returned undefined for any provider not found in the direct registry whenever at least one other provider was already registered. This prevented the plugin capability resolution fallback from discovering the ollama adapter when the ollama plugin was not loaded into the main plugin registry (e.g. omitted from plugins.allow, or not yet activated during startup).

Fix: Remove the short-circuit guard so the function always falls back to resolvePluginCapabilityProviders() when the requested provider id is not found among directly registered adapters.

Closes #63429

Changes

• src/plugins/memory-embedding-provider-runtime.ts — remove the listRegisteredMemoryEmbeddingProviders().length > 0 early-exit in getMemoryEmbeddingProvider(); always fall back to plugin capability resolution for unregistered provider ids
• src/plugins/memory-embedding-provider-runtime.test.ts — update the third test case to verify the new fallback behavior (was previously asserting the broken behavior)

Testing

• Updated unit test now verifies that requesting ollama when only openai is directly registered correctly falls back to capability resolution and finds the ollama adapter
• Existing tests for direct-registry preference and cold-registry fallback remain unchanged

---

This PR was generated with AI assistance (Claude).

Changed files

• src/plugins/memory-embedding-provider-runtime.test.ts (modified, +17/-6)
• src/plugins/memory-embedding-provider-runtime.ts (modified, +14/-8)

---

PR #66269: fix(memory): restore ollama embedding adapter

• Repository: openclaw/openclaw
• Author: vincentkoc
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/66269

Description (problem / solution / changelog)

Summary

• Problem: explicit memorySearch.provider: "ollama" regressed because memory-core no longer registers a built-in ollama embedding adapter.
• Why it matters: openclaw memory status, memory search bootstrap, and related explicit Ollama embedding flows fail with Unknown memory embedding provider: ollama.
• What changed: restore the built-in ollama adapter in memory-core, include endpoint-sensitive cache-key data so different Ollama hosts do not collide, add a focused regression test, and add the changelog entry.
• What did NOT change (scope boundary): this PR does not change the broader capability-fallback behavior in src/plugins/memory-embedding-provider-runtime.ts; it fixes the concrete built-in adapter regression on current main.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #63429
• Related #66078
• Related #66163
• Related #66112
• Related #63632
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: extensions/memory-core/src/memory/provider-adapters.ts stopped including the built-in ollama adapter, so the runtime registry only contained the other built-ins and explicit ollama resolution failed fast.
• Missing detection / guardrail: there was no focused regression test asserting that built-in Ollama registration stays present.
• Contributing context (if known): the contributor PR also surfaced that cache-key data should include endpoint-specific fields to avoid collisions across multiple Ollama hosts.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/memory-core/src/memory/index.test.ts
• Scenario the test should lock in: built-in registration includes the ollama adapter with the shared default model.
• Why this is the smallest reliable guardrail: the regression is a missing built-in adapter entry, so the smallest direct check is the registered adapter list.
• Existing test that already covers this (if any): extensions/memory-core/src/memory/manager.mistral-provider.test.ts already covers the shared embedding-provider request path.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• Explicit Ollama memory embeddings work again through the built-in memory-core adapter path.
• Embedding cache keys now distinguish different Ollama hosts for the same model name.

Diagram (if applicable)

N/A

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local repo checkout
• Model/provider: Ollama memory embeddings
• Integration/channel (if any): memory-core
• Relevant config (redacted): explicit memorySearch.provider: "ollama"

Steps

1. Run pnpm test:serial extensions/memory-core/src/memory/index.test.ts -t "registers the builtin ollama embedding provider"
2. Run pnpm test:serial extensions/memory-core/src/memory/manager.mistral-provider.test.ts

Expected

• Built-in Ollama registration is present and the focused memory-core test slice passes.

Actual

• Before this PR, explicit Ollama registration was missing from the built-in adapter list.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: focused built-in registration test and manager.mistral-provider test both passed locally.
• Edge cases checked: cache-key data now includes baseUrl and sanitized headers so different Ollama endpoints do not share cached embeddings.
• What you did not verify: a full repo-wide test lane; a broader serial run in this sparse maintainer worktree hit unrelated existing contract failures outside the touched memory-core surface.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps:

Risks and Mitigations

• Risk: none beyond restoring a missing built-in adapter and tightening its cache identity.
  • Mitigation: focused regression coverage and preserved adapter semantics from the existing Ollama extension path.

Changed files

• CHANGELOG.md (modified, +1/-0)
• extensions/memory-core/src/memory/index.test.ts (modified, +17/-1)
• extensions/memory-core/src/memory/provider-adapters.ts (modified, +29/-0)