openclaw - 💡(How to fix) Fix [Bug]: Dreaming cron not auto-recreated after plugin re-enable + zero promotion despite active-memory working [1 comments, 2 participants]

Summary

Two related issues with the dreaming/memory-core system:

1. Dreaming cron not auto-recreated: After disabling the dreaming plugin, deleting its cron job, restarting the gateway, and re-enabling dreaming — the system does NOT automatically recreate the scheduled cron. The config shows dreaming.enabled: true with frequency: "0 3 * * *", but no cron job exists to trigger it.

2. Zero promotion despite active-memory working: Even with active-memory completing successfully (timeout resolved with timeoutMs: 30000), dreaming's deep phase has never promoted a single entry across 12+ days of continuous operation. All 942 short-term recall entries remain stuck at recallCount: 0, maxScore: 0.58.

Environment

• OpenClaw: 2026.5.19-beta.1
• Agents: 3 agents (all affected)
• Chat model: reasoning model (~23s per active-memory pass)
• Embedding: NVIDIA embedding via API (~1.9s latency, healthy)
• OS: Windows (x64)

Issue 1: Cron not auto-recreated

Steps to reproduce

1. Set plugins.entries.memory-core.config.dreaming.enabled = false in config
2. Delete the dreaming cron job via API
3. Restart gateway
4. Set plugins.entries.memory-core.config.dreaming.enabled = true
5. Restart gateway

Expected

The memory-core plugin should auto-create a cron job matching the configured frequency (0 3 * * *) when dreaming is re-enabled.

Actual

No cron job is created. Config shows:

{
  "dreaming": {
    "enabled": true,
    "frequency": "0 3 * * *"
  }
}

But cron list shows zero dreaming-related jobs. The dreaming system silently does nothing.

Issue 2: Zero promotion (downstream of #79026)

Current state

Deep sleep output (every night since 5/11)

# Deep Sleep
- Repaired recall artifacts: rewrote recall store.
- Ranked 0 candidate(s) for durable promotion.
- Promoted 0 candidate(s) into MEMORY.md.

Why promotion never happens

The deep phase promotion gates require ALL of:

• signalCount >= minRecallCount (3) — actual: 1 (only dailyCount)
• maxScore >= minScore (0.8) — actual: 0.58
• uniqueQueries >= minUniqueQueries (3) — actual: 1

Since memory_search never successfully recalls these entries in conversations, recallCount stays at 0, and the entries can never satisfy the gates. This is a dead loop:

Entries stored -> recallCount=0 -> can't pass gates -> never promoted -> DREAMS.md never updated

Relation to #79026

Previous issue #82755 was closed as duplicate of #79026 (lane deadlock). While the lane deadlock fix may resolve the active-memory timeout, the downstream effect on dreaming promotion is not addressed by that fix alone. Even with active-memory now completing, the recall entries are not being surfaced in conversations, so recallCount remains 0.

Questions

1. Is the cron auto-creation behavior a known limitation? Should users manually create the cron after re-enabling dreaming, or should the plugin handle this?

2. After active-memory is fixed (#79026), will recallCount actually increment? Or is there an additional issue where the recall results aren't being surfaced in conversations?

3. Should the dreaming deep phase have a fallback path? For example, if entries have been stored for >7 days with recallCount=0, should there be an alternative promotion mechanism (e.g., based on dailyCount alone)?

4. Is there a recommended way to "reset" a broken dreaming state? The current 942 entries all at 0.58 seem stuck — clearing and re-indexing might be more practical than waiting for recall to increment.

Impact

• Memory consolidation completely non-functional for 12+ days
• DREAMS.md shows stale entries (last updated 5/8)
• User sees empty "梦境日志" in webui with no new content
• All short-term memory entries accumulating without promotion