openclaw - 💡(How to fix) Fix [Bug]: Dreaming phase reports continue, but DREAMS.md stops advancing after April 26, 2026 on 2026.4.25; recovery/backfill can leave inconsistent Dream Diary state [1 participants]

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

On OpenClaw 2026.4.26, the dreaming pipeline continued to produce phase report artifacts under memory/dreaming/, but DREAMS.md stopped receiving new Dream Diary entries after April 26, 2026.

On this install, reports for April 27–29, 2026 were present for light / REM / deep, but DREAMS.md still ended at *April 26, 2026 at 3:00 AM GMT+2*.

In addition, the public recovery/backfill path did not restore a normal-looking diary entry on this install:

• openclaw memory rem-backfill --path ... wrote a date-only diary heading (*April 29, 2026*) instead of the timestamped format used by the existing diary entries.
• In one local recovery attempt, rollback/backfill handling also left the Dream Diary block structure inconsistent (duplicated/empty managed header block before the real content).

This looks related to the same regression family as #72546, but on 2026.4.26 and with an additional visible DREAMS.md structure/recovery symptom.

Steps to reproduce

1. Run OpenClaw 2026.4.26 with memory-core dreaming enabled.
2. Let normal dreaming sweeps run for multiple days.
3. Observe that dreaming phase artifacts continue to appear under:
   • memory/dreaming/light/YYYY-MM-DD.md
   • memory/dreaming/rem/YYYY-MM-DD.md
   • memory/dreaming/deep/YYYY-MM-DD.md
4. Inspect DREAMS.md.
5. Observe that the latest Dream Diary entry does not advance even though newer dreaming phase reports exist.
6. Optional recovery path:
   • run openclaw memory rem-backfill --path memory/2026-04-27.md
   • run openclaw memory rem-backfill --path memory/2026-04-28.md
   • run openclaw memory rem-backfill --path memory/2026-04-29.md
   • inspect DREAMS.md
   • optionally run openclaw memory rem-backfill --rollback

Expected behavior

If dreaming continues to produce phase report artifacts for later dates, DREAMS.md should continue to receive corresponding Dream Diary entries.

If the official backfill / rollback flow is used for recovery:

• backfilled diary entries should remain structurally consistent with the existing Dream Diary format,
• rollback should not leave duplicated or empty managed Dream Diary header blocks,
• DREAMS.md should remain well-formed after recovery attempts.

Actual behavior

Observed on this install before manual local repair:

• DREAMS.md contained Dream Diary entries only through April 26, 2026.
• At the same time, the following later dreaming reports already existed:
  • memory/dreaming/light/2026-04-27.md
  • memory/dreaming/light/2026-04-28.md
  • memory/dreaming/light/2026-04-29.md
  • memory/dreaming/rem/2026-04-27.md
  • memory/dreaming/rem/2026-04-28.md
  • memory/dreaming/rem/2026-04-29.md
  • memory/dreaming/deep/2026-04-27.md
  • memory/dreaming/deep/2026-04-28.md
  • memory/dreaming/deep/2026-04-29.md

The last visible Dream Diary headings in DREAMS.md were still April 26, 2026 entries.

During recovery testing:

• openclaw memory rem-backfill --path memory/2026-04-29.md wrote a diary entry headed only as *April 29, 2026* (date only), rather than the timestamped style already used by the file.
• On one rollback/recovery attempt, the top of DREAMS.md ended up with a duplicated empty Dream Diary header block before the real content, i.e. a malformed managed section state rather than a cleanly restored file.

Dream diary stopped at April 26, 2026:

• last visible headings in DREAMS.md were still April 26 entries
• no April 27 / 28 / 29 diary entries were present

Later dreaming phase reports were already present:

• memory/dreaming/light/2026-04-27.md
• memory/dreaming/light/2026-04-28.md
• memory/dreaming/light/2026-04-29.md
• memory/dreaming/rem/2026-04-27.md
• memory/dreaming/rem/2026-04-28.md
• memory/dreaming/rem/2026-04-29.md
• memory/dreaming/deep/2026-04-27.md
• memory/dreaming/deep/2026-04-28.md
• memory/dreaming/deep/2026-04-29.md

Recovery/backfill behavior observed locally:

• openclaw memory rem-backfill --path memory/2026-04-27.md
• openclaw memory rem-backfill --path memory/2026-04-28.md
• openclaw memory rem-backfill --path memory/2026-04-29.md
• openclaw memory rem-backfill --rollback

Observed backfill symptom:

• wrote a date-only heading such as *April 29, 2026* rather than the timestamped format already used by normal diary entries

Observed rollback/recovery symptom on one attempt:

• duplicated empty managed Dream Diary block appeared before the actual diary content

OpenClaw version

2026.4.26

Operating system

Linux 6.8.0-110-generic x86_64, Node.js 22.22.2

Install method

No response

Model

openai-codex/gpt-5.4

Provider / routing chain

OpenClaw local gateway -> OpenAI Codex provider/model route.

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Affected: users who rely on DREAMS.md as the human-readable Dream Diary output of memory-core dreaming.

Severity: Medium.

Why:

• phase reports continue to be generated, so the dreaming pipeline appears partially alive,
• but the primary human-readable diary artifact (DREAMS.md) becomes stale,
• and the public recovery path can leave the diary in an inconsistent managed-block state instead of restoring it cleanly.

Additional information

Related report:

• #72546 reports a very similar regression on 2026.4.24 where dreaming cron/harness data exist but no new visible dreaming artifacts are written.

This report is from a separate install with the same general symptom family observed on 2026.4.25, plus an additional DREAMS.md structure/recovery symptom during official backfill/rollback testing.