[memory-core] "managed dreaming cron could not be reconciled (cron service unavailable)" startup race warning

[highfly-hi]

[memory-core] "managed dreaming cron could not be reconciled (cron service unavailable)" startup race warning

Environment

• openclaw 2026.4.29
• memory-core plugin with dreaming.enabled: true
• External cron via ~/.openclaw-secretary/cron/jobs.json works correctly (job Memory Dreaming Promotion id=90f6cecb…, schedule 0 3 * * *, last run status=ok 12.2s)

Symptom

On every gateway startup the log emits:

memory-core: managed dreaming cron could not be reconciled (cron service unavailable)

The warning is harmless — the cron does run on schedule via the external cron/jobs.json reconciliation that initializes after memory-core. But the noise:

1. Hides real issues during startup log review.
2. Misleads operators into thinking dreaming is broken (it isn't).
3. Suggests memory-core queries the cron service before the cron plugin's croner module has finished registering.

Proposed fix

• memory-core should defer cron reconciliation until the cron plugin signals ready (e.g., await gateway.plugins.waitFor('cron') or subscribe to a plugin:ready:cron event).
• Alternatively, downgrade the message to info level and add a one-shot retry on next event-loop tick.

Repro

1. Enable plugins.entries.memory-core.config.dreaming.enabled = true.
2. Restart gateway, grep first 5 seconds of logs:

   journalctl --user -u openclaw-<profile>-gateway.service -n 200 | grep "memory-core"
   

3. Observe the warning, then verify via cron/jobs.json that the dreaming cron actually executes on schedule.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve.

Summary
Keep this issue open. Current main still sends the startup retry through the runtime cron-unavailable warning path, and an open PR explicitly closes this issue, so the issue should wait for that PR to land or be rejected.

Reproducibility: yes. at source level. With dreaming enabled and cron unavailable at startup, the deferred retry calls runtime reconciliation after STARTUP_CRON_RETRY_DELAY_MS, and the current focused test expects the warn-level cron-unavailable log.

Next step
No separate repair job should be queued because an open contributor PR already targets this issue with closing syntax; the maintainer action is to review, update, land, or close that PR.

Review details

Best possible solution:

Review and land the focused fix in #76099 after it is updated and proven, then close this issue and fold the later duplicate #78323 into the same resolution.

Do we have a high-confidence way to reproduce the issue?

Yes, at source level. With dreaming enabled and cron unavailable at startup, the deferred retry calls runtime reconciliation after STARTUP_CRON_RETRY_DELAY_MS, and the current focused test expects the warn-level cron-unavailable log.

Is this the best way to solve the issue?

Yes. The narrowest maintainable fix is to suppress only the bounded startup retry-window noise while preserving exhausted-retry and genuine runtime cron-unavailable warnings; the linked PR is the active path for that.

What I checked:

• current runtime warning branch: When cron is absent and dreaming is enabled, current main still warns for runtime reconciliation; only the initial startup call is demoted to debug. (extensions/memory-core/src/dreaming.ts:784, ba8a6499f02f)
• startup retry reaches runtime path: The deferred startup retry increments its attempt count and calls reconcileManagedDreamingCron with reason "runtime", which can hit the warn-level branch before cron is ready. (extensions/memory-core/src/dreaming.ts:839, ba8a6499f02f)
• existing focused test captures the noisy retry: The startup retry test advances STARTUP_CRON_RETRY_DELAY_MS while cron is still unavailable and currently expects logger.warn to contain "cron service unavailable". (extensions/memory-core/src/dreaming.test.ts:1517, ba8a6499f02f)
• open closing PR: Live PR metadata shows fix(memory-core): suppress dreaming cron transient warning during startup retry window #76099 is open, targets this startup retry-window warning, and uses closing syntax for this issue. (8b643b0496a1)
• live issue context: Live issue metadata confirms this issue remains open and includes a user confirmation on v2026.5.4 that the warning persists while dreaming still runs successfully.
• feature history: GitHub path history for the central files shows the managed dreaming cron lifecycle, startup demotion, startup retry, and adjacent no-context guard were added by separate memory-core changes. (extensions/memory-core/src/dreaming.ts:678, e84ebeafbd67)

Likely related people:

• amknight: Path history shows this contributor added the bounded startup cron retry change that the current warning path runs through. (role: introduced startup retry behavior; confidence: high; commits: e84ebeafbd67; files: extensions/memory-core/src/dreaming.ts, extensions/memory-core/src/dreaming.test.ts)
• Sanjays2402: Path history shows this contributor added the startup-only demotion for the same cron-unavailable warning family. (role: prior warning-suppression contributor; confidence: high; commits: a37321ad5f53; files: extensions/memory-core/src/dreaming.ts, extensions/memory-core/src/dreaming.test.ts)
• rubencu: Recent merged work changed the same memory-core cron warning area to skip warnings without a gateway cron-management context. (role: recent adjacent contributor; confidence: medium; commits: 2c7b87bdb8f9, 4fa6a4ee6fc6; files: extensions/memory-core/src/dreaming.ts, extensions/memory-core/src/dreaming.test.ts)
• mbelinky: Earlier path history shows this contributor added and refined managed dreaming cron reconciliation across startup and runtime lifecycle paths. (role: managed dreaming cron lifecycle contributor; confidence: medium; commits: 2f130c418f86, 4eb716062250, 8b4883d99023; files: extensions/memory-core/src/dreaming.ts, extensions/memory-core/src/dreaming.test.ts)
• steipete: Current blame and recent path history show broad recent refactors and merge work touching the same memory-core dreaming files. (role: recent area contributor and merger; confidence: medium; commits: 4e6c85d930bd, 694ca50e9775; files: extensions/memory-core/src/dreaming.ts, extensions/memory-core/src/dreaming.test.ts)

Remaining risk / open question:

• I did not run a live gateway or Vitest repro because this review was constrained to read-only inspection; the reproduction confidence comes from current source and existing test expectations.
• The linked PR still needs normal PR handling before this issue can close.

Codex review notes: model gpt-5.5, reasoning high; reviewed against ba8a6499f02f.

[M-Lietz]

Confirming on OpenClaw v2026.5.4 (commit 325df3e, Linux/systemd-user):

The startup warning persists in v5.4 — the STARTUP_CRON_RETRY_DELAY_MS=5000 / STARTUP_CRON_RETRY_MAX_ATTEMPTS=12 retry path emits the warn-level log on the very first attempt, before the cron service finishes initializing. We see 1–4 occurrences per gateway restart depending on plugin reload count.

Functional impact: zero. Dreaming runs reliably every night despite the warning:

Date	dreaming promotion complete	Result
2026-05-01 03:00:14	✅	workspaces=1, candidates=10, applied=0
2026-05-02 03:01:00	✅	workspaces=1, candidates=10, applied=0
2026-05-03 03:00:59	✅	workspaces=1, candidates=10, applied=0
2026-05-04 03:00:13	✅	workspaces=1, candidates=10, applied=3
2026-05-05 03:00:11	✅	workspaces=1, candidates=10, applied=0

Symptom in v5.4 (dreaming-szhYuPgr.js:413-417):

[plugins] memory-core: managed dreaming cron could not be reconciled (cron service unavailable).

Repeats on every plugin reload (e.g. config-driven hot reloads), not only on cold start.

The info-or-debug-during-retry approach in #76099 (and the no-context guard in #77027) both look correct given this behaviour. Happy to test a release candidate if it helps.