Skip to content

memory_search: chokidar file watcher silently stops delivering events, index goes stale #40088

Description

@nxmxbbd

Summary

The memory search vector index stops updating after the chokidar file watcher silently stops firing events. Files modified after this point are never re-indexed, causing memory_search to return 0 results for content that exists on disk. No error or warning is logged when the watcher fails.

Environment

  • OpenClaw: 2026.3.2 (85377a2)
  • OS: Ubuntu 24.04, kernel 6.17.0-14-generic (x86_64)
  • Node: v22.22.1
  • Memory search provider: openai / text-embedding-3-small
  • Config: default (no custom memorySearch settings)

Reproduction

  1. Start gateway, let it run for several hours with active agent sessions
  2. Agent tools (exec/write) modify files under memory/ and memory/subdir/ (e.g. daily notes, reference docs)
  3. Run memory_search for content that exists in recently modified files
  4. Expected: Results from the modified files
  5. Actual: 0 results. The SQLite index (~/.openclaw/memory/main.sqlite) shows stale size/mtime for the modified files

Investigation

Watcher setup (correct):
The code at manager-*.js line ~2244 creates:

chokidar.watch([
  "<workspace>/MEMORY.md",
  "<workspace>/memory.md",
  "<workspace>/memory/**/*.md"
], { ignoreInitial: true, awaitWriteFinish: { stabilityThreshold: 1500, pollInterval: 100 } })

inotify watches (incomplete):
Inspecting /proc/<gateway-pid>/fdinfo/<inotify-fd> shows only 8 watches. The memory/ directory has a watch, but subdirectories under it (e.g. memory/subdir/) do not — despite the **/*.md glob which should trigger recursive watching via chokidar.

Timeline:

  • Gateway started at T+0
  • Last successful [memory] sync: indexing memory files log entry at T+1h (triggered by a session that modified files)
  • After T+1h, 15+ files were modified by various agent sessions over the next 20 hours
  • Zero sync events occurred despite file changes
  • Flat memory/*.md files also not synced (not just subdirectory files)

No fallback:
sync.intervalMinutes defaults to 0 (disabled), so when the watcher stops working there is no periodic fallback to catch stale files.

Workaround

Setting agents.defaults.memorySearch.sync.intervalMinutes: 30 provides a safety net. openclaw memory index --force can manually trigger a full reindex.

Suggested fix

  1. Add a periodic health check / heartbeat for the watcher (e.g. verify it's still receiving test events)
  2. Consider defaulting intervalMinutes to a non-zero value (e.g. 15-30 min) as a fallback
  3. Log a warning if the watcher's ready event doesn't fire or if no change events are received for an extended period despite files being modified

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High-priority user-facing bug, regression, or broken workflow.clawsweeper:linked-pr-openClawSweeper found an open linked pull request for this issue.clawsweeper:needs-live-reproClawSweeper needs live local, crabbox, or manual validation to confirm this issue.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🐚 platinum hermitGood issue quality with a plausible reproduction path needing some confirmation.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions