openclaw - 💡(How to fix) Fix [Bug]: memory-core short-term-promotion sentinel handler is a no-op in 2026.5.7 (cron fires, nothing writes) [1 comments, 2 participants]

Bug type

Regression (worked before, now fails) — entire dreaming output path silently broken in 2026.5.7.

Beta release blocker

No (no crash, no trading impact for downstream agents — but full memory consolidation pipeline is silently dead).

Summary

In 2026.5.7, the managed Memory Dreaming Promotion cron correctly fires agentTurn with the sentinel __openclaw_memory_core_short_term_promotion_dream__ and lightContext: true, but no in-process handler executes the short-term promotion. Each fire ack-and-exits in ~2 ms with status: ok, no model, no provider, no sessionId, and no writes to any of:

• <workspace>/<agent>/memory/.dreams/events.jsonl
• <workspace>/<agent>/memory/.dreams/short-term-recall.json
• <workspace>/<agent>/memory/.dreams/phase-signals.json
• <workspace>/DREAMS.md / dreams.md
• MEMORY.md

Pre-2026.5.7 (legacy heartbeat-coupled shape) the same job spawned an isolated Grok-4.3 session that ran for 88-231 s and reliably wrote events.jsonl and DREAMS.md. The 2026.5.7 doctor migration (migrateLegacyDreamingPayloadShape in dist/doctor-cron-rXDyRUww.js) rewrites the job to the normalized in-process shape — but the handler that should consume the sentinel never runs, so the migrated job is functionally a no-op.

Steps to reproduce

1. plugins.entries.memory-core.config.enabled: true, …dreaming.enabled: true (defaults).
2. Let the doctor's migrateLegacyDreamingPayloadShape rewrite the managed Memory Dreaming Promotion job to the normalized shape (sessionTarget: isolated, payload.kind: agentTurn, payload.message: __openclaw_memory_core_short_term_promotion_dream__, payload.lightContext: true, delivery.mode: none).
3. Wait for the next scheduled fire (default 0 3 * * *).
4. Check ~/.openclaw/cron/runs/<job-id>.jsonl: latest entry has durationMs: 2, summary: __openclaw_memory_core_short_term_promotion_dream__, no model, no provider, no sessionId.
5. Check <workspace>/<agent>/memory/.dreams/events.jsonl and DREAMS.md: mtime is from the last pre-migration run, never updated since.

Observed behaviour (real-world data, my install)

~/.openclaw/cron/runs/14b2f839-9942-451c-97a1-a0d2421c7dbe.jsonl (last 3 records):

{"ts":1778086888652,"action":"finished","status":"ok","summary":"NO_REPLY","sessionId":"69fa014f-…","runAtMs":1778086800104,"durationMs":88534,"model":"grok-4.3","provider":"xai-main"}
{"ts":1778173298160,"action":"finished","status":"ok","summary":"NO_REPLY","sessionId":"916ef85a-…","runAtMs":1778173200183,"durationMs":97963,"model":"grok-4.3","provider":"xai-main"}
{"ts":1778368753139,"action":"finished","status":"ok","summary":"__openclaw_memory_core_short_term_promotion_dream__","runAtMs":1778368753126,"durationMs":2,"nextRunAtMs":1778432400000}

Last legacy run (pre-migration, 2026-05-08 03:00 AEST): 97963 ms, Grok-4.3, wrote events.jsonl. First post-migration run (2026-05-10 09:19 AEST catchup): 2 ms, no model, no session, no write.

mtime of all dreaming output paths under both claude-code/memory/.dreams/ and codex/memory/.dreams/ is frozen at the last legacy run timestamp.

Path-of-record (verified in dist)

In dist/server-methods-DStUV8Sh.js near line 3899:

const SHORT_TERM_STORE_RELATIVE_PATH = path.join("memory", ".dreams", "short-term-recall.json");
const SHORT_TERM_PHASE_SIGNAL_RELATIVE_PATH = path.join("memory", ".dreams", "phase-signals.json");
const MANAGED_DEEP_SLEEP_CRON_NAME = "Memory Dreaming Promotion";
const MANAGED_DEEP_SLEEP_CRON_TAG = "[managed-by=memory-core.short-term-promotion]";
const DEEP_SLEEP_SYSTEM_EVENT_TEXT = "__openclaw_memory_core_short_term_promotion_dream__";
const DREAM_DIARY_FILE_NAMES = ["DREAMS.md", "dreams.md"];

These paths exist and are correct — the issue is upstream of the write, not at the path layer.

Root cause hypothesis

The cron delivers the sentinel as payload.message on an agentTurn to an isolated session. The expected behaviour is that the gateway intercepts the sentinel before spawning a model session and routes it directly into memory-core's short-term-promotion routine. Observed behaviour suggests one of:

1. Sentinel handler not registered in the loaded plugin tree — gateway sees no interceptor for the sentinel string, falls through to a normal agent run, the agent runner sees an empty/light-context prompt and returns NO_REPLY immediately (would explain the 2 ms duration and missing model/sessionId).
2. Handler is registered but no-ops — acknowledges the sentinel without invoking the host engine's runShortTermPromotion path.

In both cases the on-disk artefacts never get written.

Suggested next step for maintainers

Trace the sentinel routing path: cron → server-methods → memory-core host runtime → host-engine-runtime → file write. The break is somewhere between cron-fire and the host-engine. The 2 ms run with no model field strongly suggests the cron runner short-circuits before reaching either the agent runner or the memory-core host engine.

A targeted fix candidate is in dist/dreaming-oOlVey8D.js and dist/memory-core-host-engine-runtime-C74gwHOZ.js — verify the host registers a sentinel handler at plugin init, and that server-methods-DStUV8Sh.js dispatches matching agentTurn.message values to it.

Workaround used in production

Reverted the managed cron entry in ~/.openclaw/cron/jobs.json to the legacy heartbeat-coupled shape (Grok-4.3 isolated session, no lightContext). Doctor will auto-rewrite this back to the broken shape on the next openclaw doctor cron, so the workaround is to avoid running doctor until upstream fix lands.

Environment

• OpenClaw version: 2026.5.7
• Plugin: memory-core with dreaming.enabled: true
• Cron expr: 0 3 * * *
• Platform: Windows Server 2025 Datacenter
• Node: v25.2.1