Summary

memory_search with corpus="all" consistently times out after 15s on OpenClaw 2026.6.6, while each individual corpus succeeds:

• corpus="memory" succeeds
• corpus="sessions" succeeds
• corpus="wiki" succeeds
• CLI openclaw memory search succeeds
• corpus="all" fails repeatedly with memory_search timed out after 15s

The returned warning is misleading because it reports an embedding/provider problem even though the provider probe and individual searches are healthy.

Environment

• OpenClaw: 2026.6.6 (8c802aa)
• OS: Windows Server / Windows_NT
• Node.js: v24.14.1
• Memory backend: builtin
• Embedding provider configuration:
  • provider: openai
  • model: text-embedding-v4
  • endpoint: OpenAI-compatible /embeddings
• Vector dims: 1024
• sqlite-vec: available

Observed behavior

Deep probe reports healthy provider and index:

{
  "provider": "openai",
  "model": "text-embedding-v4",
  "providerState": {
    "mode": "active",
    "providerId": "openai"
  },
  "embeddingProbe": {
    "ok": true
  },
  "vector": {
    "enabled": true,
    "storeAvailable": true,
    "semanticAvailable": true,
    "available": true,
    "dims": 1024
  },
  "indexIdentity": {
    "status": "valid"
  }
}

Individual tool calls succeed:

memory_search({ "query": "...", "maxResults": 3, "corpus": "memory" })
// succeeds, hits=3

memory_search({ "query": "...", "maxResults": 3, "corpus": "sessions" })
// succeeds, hits=2

memory_search({ "query": "...", "maxResults": 3, "corpus": "wiki" })
// succeeds, returns wiki bridge results

CLI also succeeds:

openclaw memory search --query "..." --max-results 3

But corpus="all" fails consistently, including repeated runs:

memory_search({ "query": "...", "maxResults": 3, "corpus": "all" })

Result:

{
  "results": [],
  "disabled": true,
  "unavailable": true,
  "error": "memory_search timed out after 15s",
  "warning": "Memory search is unavailable due to an embedding/provider error.",
  "action": "Check embedding provider configuration and retry memory_search."
}

The same failure occurs with maxResults: 1.

Why this looks like an all-corpus aggregation issue

The provider, embedding endpoint, sqlite-vec, and index identity all probe successfully. Individual corpora also search successfully. The failure only appears when the tool combines builtin memory/session results with supplement/wiki results under corpus="all".

This suggests the timeout likely occurs in the all-corpus aggregation path, e.g.:

builtin memory/sessions search
+ supplement/wiki search
+ merge/balance results
+ 15s tool deadline

The error attribution currently points users toward provider configuration, but the provider is not the failing component in this case.

Expected behavior

For corpus="all", the tool should ideally:

1. Run builtin memory/session search and supplement/wiki search under independent deadlines, or otherwise avoid a single slow branch failing the whole tool.
2. Return partial results when one corpus branch times out.
3. Report a more accurate warning, e.g. all-corpus aggregation timed out, instead of embedding/provider error when provider/index probes are healthy.
4. Include debug info indicating which branch timed out: memory, sessions, wiki/supplement, merge, or embedding.

Notes from 2026.6.6 diff

OpenClaw 2026.6.6 appears to improve abort/deadline propagation for memory search and embedding query paths, but the corpus="all" aggregation still times out in this environment.

In particular, the 15s tool deadline still appears to be too tight for the combined path even though individual corpora complete successfully.