openclaw - 💡(How to fix) Fix Memory Dreaming Promotion: candidates found but applied=0 (rehydratePromotionCandidate returns null for all)

Bug Description

The Memory Dreaming Promotion cron job finds 36 candidates with high scores (0.85–0.91) across all 3 workspaces, but applied=0 every time. No candidates are ever written to MEMORY.md. This has been happening since at least May 26 (last successful promotion).

Environment

• OpenClaw version: 2026.5.27 (27ae826)
• Node.js: v22.22.2
• Platform: Linux arm64 (Armbian)
• Model: xiaomi/mimo-v2.5-pro

Configuration

{
  "enabled": true,
  "phases": {
    "light": {
      "enabled": true,
      "limit": 30,
      "dedupeSimilarity": 0.9,
      "sources": ["daily", "sessions"],
      "execution": { "speed": "balanced", "thinking": "low", "budget": "cheap" }
    },
    "deep": {
      "enabled": true,
      "limit": 30,
      "minScore": 0.5,
      "minRecallCount": 0,
      "minUniqueQueries": 0,
      "recencyHalfLifeDays": 14,
      "maxAgeDays": 30,
      "sources": ["daily", "memory", "sessions", "recall"],
      "recovery": { "enabled": true },
      "execution": { "speed": "balanced", "thinking": "low", "budget": "cheap" }
    },
    "rem": { "enabled": false }
  }
}

Log Evidence

Candidate details (score 0.85–0.91, all pass filters)

memory-core: dreaming candidate details [workspace=/root/.openclaw/workspace] memory/2026-05-21.md:6-8 score=0.914 recalls=0 queries=1 components={freq=0.916,rel=0.620,div=1.000,rec=0.990,cons=1.000,concept=1.000} | memory/2026-05-21.md:11-13 score=0.914 ... | memory/2026-05-19.md:10-12 score=0.913 ... | ... (30 total)

Applied details — always none

memory-core: dreaming applied details [workspace=/root/.openclaw/workspace] none

Promotion complete — applied=0

memory-core: dreaming promotion complete (workspaces=3, candidates=36, applied=0, failed=0).

Last successful promotion (May 26)

memory-core: dreaming promotion complete (workspaces=1, candidates=1, applied=1, failed=0).

Analysis

The issue is in rehydratePromotionCandidate. After buildShortTermPromotionCandidates successfully filters candidates (36 pass all score/signal/age checks), promoteShortTermMemoryToLongTerm calls rehydratePromotionCandidate for each, which:

1. Reads the source file (e.g. memory/2026-05-21.md)
2. Calls relocateCandidateRange to match the snippet in the current file content
3. Returns null if match fails → candidate silently dropped

The candidates are sourced from short-term-recall.json where snippets were recorded by daily ingestion. If the source file was edited after ingestion (e.g. by the user or another session), the snippet no longer matches and relocateCandidateRange fails.

Expected Behavior

Candidates that pass all scoring/filtering checks should be promoted to MEMORY.md. If snippet matching fails, the system should:

• Log a warning explaining why the candidate was skipped
• Consider using line range + fuzzy matching instead of exact snippet matching
• Or use the earliestDailyAt / metadata to reconstruct the candidate content

Actual Behavior

All 36 candidates silently dropped with no explanation in logs. Only applied details: none is logged.

Additional Context

• The store file memory/.dreams/short-term-recall.json has entries with recallCount=0, dailyCount=8, groundedCount=0
• One previously promoted entry (May 13 → promoted May 26) had recallCount=5 — suggesting only user-recalled entries get promoted, despite minRecallCount=0 in config
• Files like memory/2026-05-21.md contain standard daily log content (no dreaming fence markers)
• The issue persists across versions (observed on 2026.5.26 and 2026.5.27)