openclaw - 💡(How to fix) Fix [Bug]: feishu_bot1 memory store frozen, 87 atomic-reindex tmp files accumulate

Bug type

Behavior bug (silent data loss / stuck state)

Summary

On a running Gateway with an active Feishu channel (feishu_bot1), the agent's memory SQLite store stops being updated. The store file (feishu_bot1.sqlite) was last modified on 2026-04-29 and has not changed for 13 days despite active use. Meanwhile, 87 orphaned feishu_bot1.sqlite.tmp-* files have accumulated in the memory directory, each representing one failed atomic reindex attempt.

Environment

• OS: Windows 11
• OpenClaw: 2026.5.7
• Channel: Feishu (feishu_bot1)
• Memory provider: built-in memory-core (SQLite)
• Gateway uptime: started 2026-05-12 08:30; problem persists

Evidence

File listing (C:\Users\jujit.openclaw\memory):

• feishu_bot1.sqlite: 2026-04-29, 2,936,832 bytes (frozen since Apr 29)
• feishu_bot1.sqlite-shm: 2026-05-12, 32,768 bytes
• feishu_bot1.sqlite-wal: 2026-05-12, 0 bytes
• feishu_bot1.sqlite.backup-*: 2026-03-19, 69,632 bytes
• [87 x feishu_bot1.sqlite.tmp-*]: ranging from 69,632 to 5,525,504 bytes, spanning 2026-04-22 to 2026-05-12

Agent store comparison:

• main.sqlite: 2026-03-13 (bootstrap workspace agent, extremely stale)
• feishu_bot1.sqlite: 2026-04-29 (frozen for 13 days)
• feishu_bot2.sqlite: 2026-05-12 (newer instance, updated today)

Root cause hypothesis

The Feishu channel is continuously polling/receiving messages, which keeps the feishu_bot1.sqlite database file open and locked at the SQLite level. Every time runSafeReindex fires (on session-start or search), it creates a new tmp file and attempts the rename-based swap:

build new index > create feishu_bot1.sqlite.tmp-<uuid>

rename old feishu_bot1.sqlite > feishu_bot1.sqlite.backup-<uuid> rename tmp > feishu_bot1.sqlite

The SQLite file remains WAL-journaled and actively held open by the live Feishu channel reader, so the rename of the live file to .backup keeps failing with EBUSY/EPERM. The retry logic from #76024 (6 attempts, 25ms linear backoff) likely exhausts and throws, leaving the tmp file orphaned. On the next session-start, a new reindex fires again, creating another tmp.

Expected behavior

Atomic reindex should either:

1. succeed (swap completes and the store is updated), or
2. fail gracefully without accumulating orphaned tmp files

Impact

• Agent memory is effectively frozen - new conversations are not written to the persistent store
• 87 orphaned tmp files waste disk space
• Silent data loss: users do not realize their session memories are not being saved

Additional context

• Related: Issue #64187 (Windows EBUSY during atomic reindex) was closed by PR #76024
• This may be a distinct regression: #76024 added retry for transient rename errors, but when the Feishu channel holds the DB open continuously, the error is persistent (not transient), so retry never succeeds
• Feishu channel uses a long-running message-polling loop that may keep the SQLite file handle open continuously