Active Memory Timeout: Blocking Recall Pass Überschreitet Konfiguriertes Zeitlimit

Active Memory kann seinen blockierenden Abruf-Pass nicht innerhalb des konfigurierten Timeout-Fensters abschließen. Die folgende Diagnoseausgabe erscheint konsistent:

🧩 Active Memory: timeout 8084ms message 0 chars
🔎 Active Memory Debug: none retrieved

Gateway-Protokolle bestätigen das Timeout-Verhalten:

active-memory ... done status=timeout elapsedMs=8092 summaryChars=0
embedded_run_failover_decision ... failoverReason=timeout profileFailureReason=timeout

Diagnosemanifestationen

• Timeout-Schwelle: Timeout wird bei ~8084-8092ms ausgelöst (vs. konfigurierte 8000ms), was darauf hindeutet, dass die Timeout-Prüfung nach dem Start des blockierenden Aufrufs erfolgt
• Null-Byte-Antwort: summaryChars=0 bestätigt, dass keine Zusammenfassung vor dem Timeout generiert wurde
• Modellunabhängig: Das Problem reproduziert sich bei allen getesteten Modellen:
  • openai-codex/gpt-5.4
  • ollama/glm-5.1:cloud
  • ollama/llama3.1:8b
  • ollama/gemma4:e4b
• Backend-unabhängig: Sowohl im Leerlauf als auch in Warteschlangen-/Ausgelasteten Laufzeitumgebungen tritt identisches Verhalten auf
• Provider-Kette: Betrifft openclaw → ollama Routing-Konfiguration

Umgebungskontext

Hauptursache: Synchroner Embedding-Abruf blockiert

Der Timeout tritt auf, weil Active Memorys blockierender Abruf-Pass synchronische Embedding-Abfragen gegen das Memory-Backend durchführt, bevor das LLM zur Zusammenfassung aufgerufen wird. Wenn die Embedding-Abrufphase die konfigurierte Timeout-Zeit überschreitet, wird der LLM-Aufruf nie ausgeführt.

Analyse der Fehlersequenz

┌─────────────────────────────────────────────────────────────┐
│ Active Memory Blocking Recall Pass                          │
├─────────────────────────────────────────────────────────────┤
│ 1. Memory-Abfrage (synchron)                                 │
│    └─→ Embedding-Abruf via qwen3-embedding                 │
│        └─→ Memory-Backend-Suche                             │
│            └─→ BLOCKIERT HIER (Timeout: 8084ms)             │
│                                                             │
│ 2. LLM-Zusammenfassung (nie erreicht)                        │
│    └─→ Zusammenfassungserstellung                           │
└─────────────────────────────────────────────────────────────┘

Beitragende Faktoren

1. Embedded Run Timeout-Propagation: Der embedded_run_failover_decision Protokolleintrag zeigt, dass der Active Memory Timeout sich zum Embedded Run Kontext ausbreitet und Failover-Entscheidungsprotokollierung verursacht. Dies deutet auf eine enge Kopplung zwischen Memory-Abruf und Antwortgenerierungsphasen hin.

2. Synchroner Memory-Backend-Abfrage: Die Memory-Suche verwendet synchronen Embedding-Abruf. Wenn qwen3-embedding Latenz erfährt (Netzwerk-Round-Trip zu Ollama, Modell-Laden oder Vektor-Such-Overhead), überschreitet die kumulative Verzögerung den 8000ms Timeout, bevor das erste Token generiert wird.

3. Timeout-Prüfungs-Timing: Die 84-92ms Überschreitung (8084ms tatsächlich vs. 8000ms konfiguriert) deutet darauf hin, dass:

   • Der Timeout nach jeder blockierenden Operation geprüft wird
   • Der Embedding-Abruf selbst ~8084ms dauert
   • Kein Frühbeendigungsmechanismus für Sub-Millisekunden-Timeout-Prüfungen existiert

4. Abfragemodus-Konfiguration: Die queryMode: “message” Einstellung kann vollständige Nachrichten-Einbettung anstelle von leichtgewichtiger semantischer Suche auslösen, was die Abruflatenz erhöht.

Architektonische Inkonsistenz

Das embedded Memory-Retrieval des Memory-Core-Backends implementiert nicht:

• Async/nicht-blockierenden Embedding-Abruf
• Per-Phase Timeout-Budgets (separate Budgets für Abruf vs. Generierung)
• Frühzeitige Beendigung bei ersten substantialen Ergebnis

Lösung 1: Active Memory Timeout erhöhen (Sofortige Abschwächung)

Erhöhen Sie den Timeout, um die Embedding-Abruflatenz zu berücksichtigen:

Vorher:

"active-memory": {
  "enabled": true,
  "config": {
    "timeoutMs": 8000,
    ...
  }
}

Nachher:

"active-memory": {
  "enabled": true,
  "config": {
    "timeoutMs": 30000,
    ...
  }
}

Lösung 2: Separate Timeouts für Abruf und Generierung

Konfigurieren Sie separate Timeout-Budgets für Embedding-Abruf vs. LLM-Generierung:

"active-memory": {
  "enabled": true,
  "config": {
    "timeoutMs": 30000,
    "retrievalTimeoutMs": 10000,
    "generationTimeoutMs": 20000,
    ...
  }
}

Lösung 3: Zu Async/Leichtgewichtigem Abfragemodus wechseln

Ändern Sie queryMode von “message” zu “semantic” oder “hybrid”:

Vorher:

"queryMode": "message"

Nachher:

"queryMode": "semantic"

Lösung 4: Schnelleres Embedding-Modell verwenden

Ersetzen Sie qwen3-embedding durch ein schnelleres lokales Embedding-Modell:

"active-memory": {
  "config": {
    "embeddingModel": "ollama/nomic-embed-text"
  }
}

Starten Sie dann Ollama neu, um sicherzustellen, dass das Modell gecacht ist:

ollama pull nomic-embed-text
systemctl restart ollama

Lösung 5: Active Memory vorübergehend deaktivieren (Für Produktion)

Wenn der Timeout die Produktion blockiert, deaktivieren Sie den blockierenden Abruf:

"active-memory": {
  "enabled": false
}

Oder beschränken Sie auf nicht-blockierenden Modus:

"active-memory": {
  "config": {
    "blockingMode": false,
    "asyncRecall": true
  }
}

Lösung 6: Memory-Backend-Integritätsprüfung

Überprüfen Sie die Memory-Backend-Konnektivität und den Indexierungsstatus:

# Memory-Backend-Status prüfen
openclaw memory status

# Embedding-Modell-Verfügbarkeit verifizieren
ollama list | grep qwen3-embedding

# Memory-Suchlatenz manuell testen
openclaw memory search "test query" --verbose

Verifizierungsschritte nach Anwenden der Lösungen

Schritt 1: Ausführliches und Trace-Logging aktivieren

/verbose on
/trace on

Schritt 2: Active Memory Abruf auslösen

Senden Sie eine Nachricht, die einen Memory-Abruf auslösen sollte:

what was my last message to you

Schritt 3: Nicht-Timeout-Verhalten verifizieren

Erwartete Ausgabe (Erfolg):

🧩 Active Memory: completed 2341ms message 87 chars
🔎 Active Memory Debug: retrieved summary "User asked about..."

Erwartetes Gateway-Protokoll:

active-memory ... done status=success elapsedMs=2345 summaryChars=87

Schritt 4: Bestätigen, dass kein Failover ausgelöst wurde

Verifizieren Sie das Fehlen von:

embedded_run_failover_decision ... failoverReason=timeout

Schritt 5: Diagnose-Befehl ausführen

openclaw memory test --mode recall --verbose

Erwartete Ausgabe:

Memory recall test: PASS
Retrieval latency: 1243ms
Generation latency: 892ms
Total: 2135ms (within timeout budget)

Schritt 6: Memory-Backend-Integrität verifizieren

openclaw memory status

Erwartete Ausgabe sollte anzeigen:

• backend: memory-core
• indexed: true
• embedding: qwen3-embedding (or configured model)
• status: healthy

• Timeout zu nah an der Embedding-Latenz: Wenn Sie timeoutMs nur geringfügig höher als die typische Embedding-Abruflatenz einstellen, bleibt kein Budget für die LLM-Generierung. Stellen Sie sicher, dass der Gesamttimeout beide Phasen plus 20% Puffer berücksichtigt.

• Ollama-Modell nicht vor-geladen: Bei der ersten Anfrage lädt Ollama das Embedding-Modell herunter und lädt es, was erhebliche Latenz verursacht. Laden Sie Modelle immer vor:

  ollama pull ollama/gemma4:e4b
  ollama pull qwen3-embedding

• Netzwerklatenz mit Remote Ollama: Wenn Ollama auf einem Remote-Host oder Docker-Container läuft, summiert sich die Netzwerklatenz zur Embedding-Abruflatenz. Verwenden Sie lokales Ollama oder erhöhen Sie den Timeout um das 2-3-fache.

• Memory-Index nicht erstellt: Wenn das Memory-Backend keinen indizierten Inhalt hat, führt der Abruf-Pass möglicherweise trotzdem Embedding-Abfragen gegen leere Ergebnisse aus, was unerwartete Latenz verursacht. Überprüfen Sie den Indexstatus, bevor Sie den Timeout beheben.

• Blockierungsmodus-Überschreibung: Einige Konfigurationen oder Plugins können blockingMode: true unabhängig von Benutzereinstellungen erzwingen. Prüfen Sie auf:

  openclaw config get active-memory.blockingMode

• Discord DM-Spezifika: Das Problem wurde im Discord DM-Kontext beobachtet. Andere Plattformen (Slack, Teams, Terminal) können aufgrund von Gateway-Implementierungsunterschieden abweichendes Timeout-Verhalten aufweisen.

• Versionsinkongruenz: Das Problem wurde auf 2026.4.12 gemeldet, erwähnt aber 26.4.14. Stellen Sie sicher, dass sowohl Client als auch Gateway auf derselben Version sind, da sich die Timeout-Behandlung zwischen Releases geändert haben kann.

• Parallele Memory-Operationen: Wenn mehrere Memory-Operationen parallel ausgeführt werden (Indizierung, Suche, Abruf), können sie um Embedding-Modell-Ressourcen konkurrieren. Queue Memory-Operationen oder verwenden Sie dedizierte Embedding-Instanzen.

• embedded_run_failover_decision: Failover-Entscheidung ausgelöst durch Timeout-Propagation vom Active Memory blockierenden Abruf zum Embedded Run Kontext.

• memory.search.timeout: Memory-Backend-Suchoperation überschritt ihre Timeout-Schwelle (kann unabhängig oder als Teil des Active Memory-Fehlers auftreten).

• embedding.model.not_found: Das konfigurierte Embedding-Modell (qwen3-embedding) ist in Ollama nicht verfügbar, was synchronen Fallback-Verzögerungen vor dem Timeout verursacht.

• active-memory.summary_chars=0: Active Memory wurde abgeschlossen, aber null Zeichen generiert, was darauf hindeutet, dass die Zusammenfassungsphase entweder übersprungen wurde oder still fehlschlug.

• gateway.active_memory.done.status=timeout: Gateway-Level-Status, der anzeigt, dass die Active Memory-Operation mit Timeout-Status abgeschlossen wurde, unterschieden von status=success oder status=error.

• llm.context.window.exceeded: Kann auftreten, wenn die Memory-Abruf-Zusammenfassung in nachfolgenden Anfragen eingeschlossen wird und Kontextlimits überschreitet, zusammenhängend mit maxSummaryChars Fehlkonfiguration.

• Historisch: v2026.3.x Memory-Backend-Regressionen: Frühere Versionen hatten bekannte Probleme mit Memory-Abruf-Latenz aufgrund von Backend-Initialisierung. Stellen Sie nach einem Upgrade einen frischen Index-Wiederaufbau sicher.