mem0ai/mem0 · critical · RuntimeError

Mem0 runtime has not been initialized.

Error message

Mem0 runtime has not been initialized.

What it means

Raised by get_memory_instance() in server/server_state.py when the shared Mem0 Memory runtime is requested before initialize has stored it in _memory_instance. The server lazily initializes the memory runtime during startup/config application; any route or job that needs Memory must go through this accessor, and calling it before initialization completes (or after a failure) raises this RuntimeError.

Source

Thrown at server/server_state.py:106

    with _state_lock:
        next_config = _merge_config(_current_config, updates)
        _current_config = next_config
        _memory_instance = Memory.from_config(next_config)
        overrides = _load_overrides()
        overrides = _merge_config(overrides, updates)
        _save_overrides(overrides)
        return deepcopy(_current_config)


def get_current_config() -> Dict[str, Any]:
    with _state_lock:
        return deepcopy(_current_config)


def get_memory_instance() -> Memory:
    with _state_lock:
        if _memory_instance is None:
            raise RuntimeError("Mem0 runtime has not been initialized.")
        return _memory_instance

View on GitHub (pinned to 001c235229)

Solutions

  1. Ensure the server's startup/config-initialization path runs before serving requests (FastAPI startup handler / lifespan that calls the initialize function in server_state)
  2. Check server logs for a failed initialization (invalid API keys, unreachable vector store) and fix the underlying config error, then restart so init completes
  3. In tests, call the initialization helper (or a fixture that applies a test config) before invoking get_memory_instance()
  4. Guard early requests: return 503 from memory routes when get_memory_instance() raises, so clients retry after startup completes

Example fix

# before: module-level call at import time, before startup ran
memory = get_memory_instance()

# after: resolve lazily inside the request handler after startup
from fastapi import HTTPException

def memory_or_503():
    try:
        return get_memory_instance()
    except RuntimeError:
        raise HTTPException(status_code=503, detail="Mem0 runtime is not ready yet.")
Defensive patterns

Strategy: try-catch

Validate before calling

from server.server_state import get_current_config

# a config that exists implies initialization ran (or will run) on startup
cfg = get_current_config()
# in FastAPI: put init in the lifespan/startup handler so it always precedes traffic

Type guard

def memory_ready() -> bool:
    from server import server_state
    with server_state._state_lock:
        return server_state._memory_instance is not None

Try / catch

try:
    memory = get_memory_instance()
except RuntimeError:
    raise HTTPException(status_code=503, detail="Memory runtime not ready")  # client retries with backoff

Prevention

When it happens

Trigger: A request hits a memory-backed endpoint before the startup initialization has run (e.g. config was never applied, or the app was imported and called directly without the startup hook); initialization failed earlier (bad LLM/vector-store config) leaving _memory_instance None while the API still serves; a background task starts before server startup finishes; tests call get_memory_instance() without booting server state.

Common situations: Missing or invalid MEM0/LLM environment variables so startup init silently skipped or failed; running the FastAPI app in a test harness that never triggers startup events; race on slow initialization where early requests arrive first; config update path reset the runtime and no re-init followed.

Related errors


AI-assisted analysis of mem0ai/mem0@001c235229 (2026-08-15). Data as JSON: /api/errors/c603c3518cf109de. Report an issue: GitHub.