PR #66139: fix(memory-core): run Dreaming once per cron schedule

• Repository: openclaw/openclaw
• Author: mbelinky
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/66139

Description (problem / solution / changelog)

Summary

• Problem: managed Dreaming could re-trigger on later heartbeat turns even after the cron event had already been consumed.
• Why it matters: this creates repeated empty Dreaming-related sessions and extra sweep churn instead of running once per schedule.
• What changed: gate the Dreaming heartbeat trigger on a real pending queued cron:* Dreaming system event, with isolated-heartbeat fallback to the base session queue.
• What did NOT change (scope boundary): this does not broaden into the separate cron-service-unavailable reconciliation issue.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #65705
• Related #65652
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: the before_agent_reply Dreaming hook treated the rendered heartbeat prompt text as the trigger source, so the same Dreaming token could be re-detected on later heartbeats even after the original cron event had already been handled.
• Missing detection / guardrail: the trigger path did not verify that a live queued Dreaming cron:* system event still existed for the session being processed.
• Contributing context (if known): isolated heartbeat runs use a sibling :heartbeat session while cron events stay queued on the base session.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/memory-core/src/dreaming.test.ts
• Scenario the test should lock in: stale Dreaming token text without a pending cron event must not retrigger; isolated heartbeat sessions must still honor the base-session queued cron event.
• Why this is the smallest reliable guardrail: the bug lives at the plugin hook plus session-queue seam, not in the cron expression math itself.
• Existing test that already covers this (if any): src/infra/heartbeat-runner.ghost-reminder.test.ts already covers the core queue-drain contract for cron-tagged system events.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Dreaming now runs once per cron schedule instead of replaying on subsequent ordinary heartbeats after the scheduled event has already been consumed.

Diagram (if applicable)

Before:
[cron fires] -> [heartbeat prompt includes Dreaming token] -> [Dreaming runs]
[next heartbeat still contains replayed token text] -> [Dreaming runs again]

After:
[cron fires] -> [queued Dreaming cron event exists] -> [Dreaming runs once]
[next heartbeat without queued cron event] -> [no Dreaming replay]

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local repo worktree
• Model/provider: N/A
• Integration/channel (if any): heartbeat / cron / memory-core Dreaming
• Relevant config (redacted): memory-core Dreaming enabled with managed cron schedule; isolated heartbeat path also exercised

Steps

1. Queue a managed Dreaming cron system event for the main session.
2. Run a heartbeat that contains the Dreaming token and let the Dreaming hook handle it.
3. Run a later heartbeat with the same token text but without a pending queued cron event.

Expected

• Dreaming runs only for the heartbeat backed by the queued cron event.
• Later heartbeats do not retrigger unless a new cron event is actually pending.

Actual

• Before the fix, later heartbeats could retrigger Dreaming from stale/replayed token text alone.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: targeted Dreaming regression tests, isolated-heartbeat queue behavior, and core cron-event drain behavior.
• Edge cases checked: base-session queued cron events for isolated :heartbeat runs; replay-shaped stale prompt text without a pending event.
• What you did not verify: a full live gateway reproduce-before / verify-after run on this machine.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps:

Risks and Mitigations

• Risk: a future synthetic before_agent_reply caller that omits sessionKey would suppress Dreaming instead of triggering it.
  • Mitigation: current production wiring passes sessionKey, and suppression is safer than replay.

Changed files

• CHANGELOG.md (modified, +1/-0)
• extensions/memory-core/src/dreaming.test.ts (modified, +132/-3)
• extensions/memory-core/src/dreaming.ts (modified, +37/-0)