memory_search can fail with Cannot read properties of undefined (reading 'get') due to corrupted shared singleton cache

Summary

memory_search can become unavailable in the long-running gateway process even while fresh CLI invocations still work.

The user-visible tool result is:

{
  "results": [],
  "disabled": true,
  "unavailable": true,
  "error": "Cannot read properties of undefined (reading 'get')",
  "warning": "Memory search is unavailable due to an embedding/provider error."
}

The warning is misleading here. The actual failure can be a corrupted global singleton cache shape, not an embedding/provider failure.

Environment

• OpenClaw: 2026.4.15
• Node: 22.22.0
• Gateway mode: long-running systemd user service
• Memory provider: local
• No usable GPU; local embeddings fall back to CPU successfully

What I observed

Fresh CLI works:

• openclaw memory status --agent main reports Provider: local, Vector: ready, FTS: ready
• openclaw memory search ... returns normal results

But the gateway process could still return the broken memory_search result above.

Root cause

The failure is reproducible by corrupting the shared singleton cache on globalThis before loading the memory runtime.

Relevant compiled runtime areas in 2026.4.15:

• extensions/memory-core/src/memory/search-manager.ts
• extensions/memory-core/src/memory/manager-cache.ts

Current behavior:

1. memory_search uses a shared singleton cache keyed by:
   • Symbol.for("openclaw.memorySearchManagerCache")
   • Symbol.for("openclaw.memoryIndexManagerCache")
2. The returned singleton object shape is not validated before code uses .get(...)
3. If some prior code path or mixed runtime state leaves an invalid object in that global slot, later access crashes with:
   • Cannot read properties of undefined (reading 'get')
4. The exception is then wrapped into the generic "embedding/provider error" unavailable result

Minimal repro

This reproduces the exact undefined.get failure for the search manager cache:

node --input-type=module -e '
globalThis[Symbol.for("openclaw.memorySearchManagerCache")] = {};
import("/path/to/openclaw/dist/memory-CJrwLxmz.js").then(async (m) => {
  await m.n({ cfg: { memory: { backend: "qmd", qmd: {} } }, agentId: "main", purpose: "search" });
});
'

Before adding shape validation, this crashes with:

TypeError: Cannot read properties of undefined (reading 'get')

Proposed fix

Validate the singleton cache shape when resolving these global stores. If the object shape is invalid, rebuild it instead of trusting it.

Pseudo-fix:

function getMemorySearchManagerCacheStore() {
  const existing = resolveGlobalSingleton(MEMORY_SEARCH_MANAGER_CACHE_KEY, () => ({
    qmdManagerCache: new Map()
  }));
  if (existing && existing.qmdManagerCache instanceof Map) return existing;

  const repaired = {
    ...(existing && typeof existing === "object" ? existing : {}),
    qmdManagerCache: new Map()
  };
  globalThis[MEMORY_SEARCH_MANAGER_CACHE_KEY] = repaired;
  return repaired;
}

And similarly for the managed cache used by the memory index manager:

function resolveSingletonManagedCache(cacheKey) {
  const existing = resolveGlobalSingleton(cacheKey, () => ({
    cache: new Map(),
    pending: new Map()
  }));
  if (existing && existing.cache instanceof Map && existing.pending instanceof Map) {
    return existing;
  }

  const repaired = {
    ...(existing && typeof existing === "object" ? existing : {}),
    cache: new Map(),
    pending: new Map()
  };
  globalThis[cacheKey] = repaired;
  return repaired;
}

Secondary issue

The user-facing wrapper currently reports this as:

• "Memory search is unavailable due to an embedding/provider error."

That is too broad. It hides non-provider failures like singleton cache corruption.

It would help to:

1. Preserve a more accurate error classification
2. Include the real underlying failure reason in logs
3. Avoid defaulting all memory manager exceptions to "embedding/provider error"

Why this matters

This creates a confusing split-brain state:

• CLI appears healthy
• gateway/user-facing memory_search is broken

That makes the issue hard to diagnose and easy to misattribute to the local embedding provider.