-
Notifications
You must be signed in to change notification settings - Fork 331
Closed
Description
Problem
When OpenMemory starts with an existing SQLite database, existing memories fail to load despite being present in the database file.
Symptoms:
- Backend logs show:
[INIT] Initial decay: 0/0 memories updated - Dashboard and MCP API show no memories
- SQLite database contains all memories (verified with
SELECT COUNT(*) FROM memories) - Affects SQLite backend only (PostgreSQL not affected)
Environment:
- OpenMemory v1.2.2
- SQLite backend (default configuration)
- Docker deployment with bind-mounted database
- Container restart scenario
Root Cause
Race condition: The run_decay_process() function executes immediately after module load (line 101 in backend/src/server/index.ts), before SQLite's async initialization completes.
Reproduction Steps
- Store memories in OpenMemory with SQLite backend
- Restart the Docker container
- Check logs:
docker logs <container> - Observe:
[INIT] Initial decay: 0/0 memories updated - Verify database has data:
sqlite3 ./data/openmemory.sqlite "SELECT COUNT(*) FROM memories;"
Expected Behavior
- All existing memories should load on startup
- Logs should show:
[INIT] Initial decay: X/X memories updatedwhere X = number of memories in database
Proposed Solution
Add a small initialization delay (3 seconds) before running the initial decay process to ensure SQLite connection is fully established.
Impact
This is a critical bug for users who:
- Use SQLite (default configuration)
- Have existing data
- Restart containers or upgrade versions
- Use Docker with bind-mounted databases
Metadata
Metadata
Assignees
Labels
No labels