openclaw - 💡(How to fix) Fix [Bug]: active-memory logging:true does not emit recall events to gateway journal or runtime log [1 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

plugins.entries.active-memory.config.logging = true is documented to surface recall events for observability. With logging: true set and the gateway restarted, no [active-memory] lines appear in the gateway journal or runtime log during real recall events. Recall traces are visible in session trajectory files, but those are not the operator-facing log surface.

Steps to reproduce

# Confirm the config and restart
$ openclaw config get plugins.entries.active-memory --json | jq '.config.logging'
true
$ systemctl --user restart openclaw-gateway && sleep 5

# Trigger a recall (asks for a remembered fact)
$ openclaw agent --agent main --message "Reply with the city I live in"
Glasgow

# Search journal for any active-memory log line
$ journalctl --user -u openclaw-gateway --since "1 minute ago" | grep -iE "active-memory|recall|preference"
# (no output)

# But trajectory shows recall fired (168 mentions in session file)
$ grep -c "active-memory" ~/.openclaw/agents/main/sessions/*.trajectory.jsonl
168

Expected behavior

With plugins.entries.active-memory.config.logging = true, recall events should be observable from the standard operator log surfaces — journalctl --user -u openclaw-gateway and /tmp/openclaw/openclaw-YYYY-MM-DD.log. At minimum:

• INFO line per recall: [active-memory] recall fired (model=<m>, hits=<n>, ms=<t>)
• WARN line when recall fall-through behavior occurs (model unreachable, empty response, etc.)

This matches the documented purpose of the logging: true flag and the operational expectation set by other plugins (cron / channels / msteams all log to journal at INFO when active).

Actual behavior

journalctl and /tmp/openclaw/*.log contain no [active-memory] lines during active recall. The only active-memory references in the journal are gateway-boot lines (http server listening (9 plugins: active-memory, ...)). Recall events are visible only in ~/.openclaw/agents/<id>/sessions/<uuid>.trajectory.jsonl, which mixes agent-internal traces with plugin emit events and is session-scoped (one file per session).

OpenClaw version

2026.5.7 (eeef486)

Operating system

Ubuntu 24.04

Install method

npm global at /usr/local, system Node v22.22.2 (apt, held)

Model

active-memory configured model: google/gemini-3-flash-preview (recall model). Primary agent model anthropic/claude-opus-4-7. Recall behavior reproduces independent of agent's primary model.

Provider / routing chain

openclaw -> google (api_key, gemini-3-flash-preview for recall) — recall fires correctly, only logging is missing.

Additional provider/model setup details

{
  "plugins": {
    "entries": {
      "active-memory": {
        "config": {
          "setupGraceTimeoutMs": 30000,
          "agents": ["main"],
          "allowedChatTypes": ["direct"],
          "model": "google/gemini-3-flash-preview",
          "promptStyle": "preference-only",
          "timeoutMs": 15000,
          "logging": true
        }
      }
    }
  }
}

Logs, screenshots, and evidence

# logging:true is set
$ openclaw config get plugins.entries.active-memory --json | jq '.config.logging'
true

# Recall fires (verified via trajectory)
$ grep -c "active-memory" ~/.openclaw/agents/main/sessions/*.trajectory.jsonl
168

# But no journal output
$ journalctl --user -u openclaw-gateway --since "1 hour ago" | grep -i "active-memory"
May 09 04:42:31 kaveh-dev-01 openclaw[12345]: [plugins] http server listening (9 plugins: active-memory, ...)
# (only the boot-line — no per-recall events)

Impact and severity

• Affected: anyone using active-memory who wants to debug recall behavior without resorting to session-trajectory archaeology.
• Severity: medium (observability gap; functional but operationally hard to debug).
• Frequency: every recall event silently skips the journal log surface.
• Consequence: when recall behaves unexpectedly ("why did the agent forget X?"), operator cannot answer "did active-memory dispatch a recall? what model? was it cached? was there a fallback?" via the standard journalctl | grep workflow. Has to grep across many session trajectory files and parse each for plugin-internal events. Cost on this deployment: ~30 min per recall-suspected investigation, several times since active-memory was enabled (TASK-033 / TASK-035).

Additional information

active-memory is high-value (closes the "feels like it forgets things" complaint per ISS-042 in our internal tracker). The current observability story being "look at trajectory files" is a notable gap relative to the rest of the plugin surface, which uses the journal as the canonical operator log. A few INFO lines per recall would close the gap immediately.

The logging: true flag implies the events should be available on a standard log surface — the documentation for this flag should either match its current behavior (i.e., "logging:true enables session-trajectory-only logging") or the plugin should match the documentation (emit to journal/runtime log when set).