Bug type

Reliability / session-liveness bug

Summary

A failed or stalled memory_search can paralyze a live session instead of degrading gracefully.

In our case, the assistant reached a memory_search tool call during a live Telegram turn, and the turn never completed. From the user perspective, the bot looked dead even though the gateway process and Telegram token were still fine.

This is worse than “memory_search returns empty results.” It is a liveness bug: one memory tool call can wedge the whole turn.

Environment

• OpenClaw: 2026.3.13
• OS: macOS
• Channel: Telegram
• Agent: main-telegram
• Memory config included:
  • sources: ["memory", "sessions"]
  • experimental.sessionMemory: true
  • extraPaths pointing at an Obsidian/iCloud vault
  • provider: openai
  • model: text-embedding-3-small

Relevant config shape:

{
  "agents": {
    "defaults": {
      "memorySearch": {
        "sources": ["memory", "sessions"],
        "extraPaths": [
          "/Users/<user>/Library/Mobile Documents/iCloud~md~obsidian/Documents/<vault>"
        ],
        "experimental": {
          "sessionMemory": true
        },
        "provider": "openai",
        "model": "text-embedding-3-small"
      }
    }
  }
}

Observed behavior

During a live chat turn:

1. the assistant invoked memory_search
2. the turn did not complete
3. the user got no reply
4. the active session appeared wedged until manual intervention

Additional observations from logs / runtime:

• memory sync failures were logged, including:
  • memory sync failed (session-start): ...
  • memory sync failed (session-delta): ...
  • Unknown system error -11, read
• watcher instability also appeared around an iCloud/Obsidian extra path:
  • unhandled EINTR
• direct outbound Telegram API send still worked
• gateway process was still running

This suggests the bot was not fully down; the turn pipeline got stuck around memory handling.

Expected behavior

memory_search should never be able to wedge the entire turn.

If memory retrieval is unhealthy, the runtime should fail open and return a tool result like:

• disabled: true
• unavailable: true
• error/timeout metadata

The assistant should then continue the turn with a degraded reply such as “memory retrieval is unavailable right now.”

Why this appears to be a real bug

Looking at the installed runtime:

• memory_search does catch ordinary thrown errors and returns an unavailable result
• background memory sync failures are also logged with .catch(...)

So the dangerous path seems to be a narrower setup/runtime condition where the tool call is emitted but the normal failure result never makes it back to the model/session.

Likely areas:

• getMemorySearchManager(...)
• MemoryIndexManager.get(...)
• provider/index initialization
• an unhealthy memory source path causing the tool-result path not to complete

Impact

High.

This turns a memory retrieval problem into a user-visible “bot is dead” incident.

Mitigations tried

• disabling memory watch reduced instability:
  • agents.defaults.memorySearch.sync.watch = false

This appears to help, but it is only a mitigation, not a root-cause fix.

Suggested fix

1. Add a hard timeout to memory_search
2. Guarantee a tool result is always returned, even on setup/init failure
3. Treat optional memory sources (extraPaths, session memory, watched paths) as fail-open
4. Add watchdog behavior for “tool call emitted but no tool result returned”
5. Ensure memory subsystem failures cannot silence the final assistant reply

Related issues

This may be related to the broader family of memory integration bugs, but this report is specifically about session paralysis / liveness failure, not merely empty results.