Skip to content

[BUG] SQLite memories not loading on container startup (race condition) #94

@fparrav

Description

@fparrav

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

  1. Store memories in OpenMemory with SQLite backend
  2. Restart the Docker container
  3. Check logs: docker logs <container>
  4. Observe: [INIT] Initial decay: 0/0 memories updated
  5. 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 updated where 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

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions