3.9 KiB
3.9 KiB
OpenMemory (mem0)
Selbst-gehosteter Memory-Store mit MCP-Schnittstelle. Wird u. a. von Cursor und Jervais/Hermes als persistentes Gedaechtnis genutzt.
Deployment
- Host: CT122 auf pve-hetzner (Tailscale-Gateway
root@100.88.230.59), interne IP10.10.10.122. - Container: Docker Compose unter
/root/mem0/openmemory/(docker-compose.yml):openmemory-openmemory-mcp-1(mem0/openmemory-mcp) — API/MCP auf Port8765,uvicorn main:app --reload --workers 4.openmemory-mem0_store-1(qdrant/qdrant) — Vektor-Store, Collectionopenmemory.openmemory-openmemory-ui-1(mem0/openmemory-ui) — Dashboard auf Port3000.
- App-Quellcode (bind-mount): Host
/root/mem0/openmemory/api→ Container/usr/src/openmemory. - Aktive Konfiguration: NICHT
config.json, sondern DB-Tabelleconfigs(keymain) in/usr/src/openmemory/openmemory.db. LLM =gpt-4o-minivia OpenRouter (OPENAI_BASE_URL=https://openrouter.ai/api/v1), Embeddertext-embedding-3-small. - Zugang vom Cursor-Host: SSH-Tunnel
openmemory-tunnel.service(autossh) leitetlocalhost:8765→10.10.10.122:8765. MCP-URL inmcp.json:http://localhost:8765/mcp/cursor/sse/orbitalo. - Logs:
docker logs openmemory-openmemory-mcp-1(json-file, keine Rotation konfiguriert).
Hotfix — 2026-05-31
Behob zwei Fehlfunktionen.
Symptome
list_memorieslieferte hart:Error getting memories: fromisoformat: argument must be str.add_memoriesmit laengeren Texten gab still{"results": []}zurueck (nicht gespeichert), ohne sichtbaren Client-Fehler.
Root Causes
- Gemischte Timestamp-Typen in qdrant. 274 von 663 Punkten hatten
hashundcreated_atals Integer (alte Records einer frueheren mem0-Version), neuere als String/ISO.mem0.memory.main._normalize_iso_timestamp_to_utc()fing nurValueError; bei int wirftdatetime.fromisoformat()einTypeError→get_all/list_memoriescrasht komplett.- Zusaetzlich verlangt das Pydantic-Modell
MemoryItemStrings fuerhash/created_at→ValidationErrorbei int.
- Truncation des Extraktor-LLM-JSON.
max_tokens: 2000zu klein; beim Update-Memory-Schritt (Prompt enthaelt alle bestehenden Memories) wurde das JSON abgeschnitten →Invalid JSON response→ leeresresults.- Hinweis: Leeres
resultskann AUCH legitim sein (LLM-Dedup →event: NONE/NOOP). Nur das abgeschnittene JSON ist der Bug.
- Hinweis: Leeres
Fixes (angewendet + verifiziert)
- qdrant-Daten normalisiert: 274 Records,
hashint→str,created_at/updated_atepoch-int→ISO-UTC. Backup:api/qdrant_intfix_backup-20260531.json. - mem0-Library tolerant:
site-packages/mem0/memory/main.pyexcept ValueError:→except (ValueError, TypeError):. Backup.bak-tsfix-20260531(NICHT rebuild-fest). - Durabler Monkeypatch (rebuild-fest): in
api/main.pynach den Imports — ueberschreibt_normalize_iso_timestamp_to_utcso, dass Nicht-String-Werte unveraendert durchgereicht werden. Backupapi/main.py.bak-tsfix-20260531. - max_tokens erhoeht: DB-Config
configs.main→mem0.llm.config.max_tokens2000→8000. Backupapi/config_main.bak-20260531.json.
Verifikation
_normalize_iso_timestamp_to_utc(1774205916)gibt int zurueck statt Crash; ISO weiterhin korrekt.list_memories()liefert JSON-Array (100), 0 verbleibende int-Records.- Langer
add_memories→ gueltiges JSON,event: ADD(Dedup korrektNONE/NOOP). - Live ueber Cursor-MCP (nach Client-Reload) beide Tools ok.
Nach Container-Rebuild beachten
- Persistent: Fix 1 (qdrant-Daten), Fix 3 (Monkeypatch in
main.py), Fix 4 (DB-Config). - Verloren bei Image-Rebuild: Fix 2 (site-packages) — durch Fix 3 abgedeckt.
- Container-Neustart invalidiert MCP-Sessions → Clients muessen neu initialisieren (
-32602= request before initialization). In Cursor: MCPopenmemorytoggeln oder Fenster neu laden.