Environment

• openclaw 2026.4.21 (commit f788c88)
• Bundled memory-core plugin, dreaming sub-feature (config.enabled: true)
• node v25.6.1
• macOS 26.2 (Darwin 25.2.0)

Summary

reconcileManagedDreamingCron in dist/dreaming-CDsj6KD1.js is invoked on gateway:startup and on every heartbeat-triggered before_agent_reply. On startup, the cron service often hasn't initialized yet (race), so the function emits a once-per-process warning gated by unavailableCronWarningEmitted. The warning self-deduplicates within a process, but fires once per gateway restart whenever config.enabled === true. This is a low-priority sub-issue filed alongside the sessions.delete scope ticket from the same plugin.

Reproduction

1. plugins.entries.memory-core.config.dreaming.enabled = true (the bundled default).
2. openclaw daemon restart.
3. Within ~10 seconds, gateway.err.log contains:

   2026-04-25T09:35:09-04:00 [plugins] memory-core: managed dreaming cron could not be reconciled (cron service unavailable).

Observed behavior

• 14 occurrences in production gateway.err.log over 13 days — once per gateway restart, suppressed thereafter within the same process.
• The warning is benign in isolation but contributes noise to ops grading layers that count error-log lines per process.
• Disabling dreaming (config.enabled = false) silences this too — the warning is gated on config.enabled at the same line — but if dreaming is genuinely wanted, the warning is unavoidable on every restart.

Expected behavior

On startup, defer reconciliation until the cron service is ready (a brief retry window, e.g. 5–30s), or make reconcileManagedDreamingCron reentrant/idempotent so the first call doesn't need to fail when cron is still initializing. Either path eliminates the warning while preserving the safety check for genuinely missing cron service.

Evidence

Code — dist/dreaming-CDsj6KD1.js:1465-1478:

const reconcileManagedDreamingCron = async (params) => {
  const startupCfg = params.reason === "startup" && params.startupEvent !== void 0 ? resolveStartupConfigFromEvent(params.startupEvent, api.config) : api.config;
  const config = resolveShortTermPromotionDreamingConfig({...});
  if (params.reason === "startup" && params.startupEvent !== void 0) startupCronSource = resolveStartupCronSourceFromEvent(params.startupEvent);
  const cron = resolveCronServiceFromStartupSource(startupCronSource);
  const configKey = runtimeConfigKey(config);
  if (!cron && config.enabled && !unavailableCronWarningEmitted) {
    api.logger.warn("memory-core: managed dreaming cron could not be reconciled (cron service unavailable).");
    unavailableCronWarningEmitted = true;
  }
  if (cron) unavailableCronWarningEmitted = false;
  ...
};

The race: when params.reason === "startup" runs before the cron service has populated, cron is undefined → warn → set the dedup flag. A subsequent heartbeat-triggered before_agent_reply sees cron populated and clears the flag, but the startup warning is already in the log.

Production log evidence (recurring across restarts):

2026-04-25T09:35:09-04:00 [plugins] memory-core: managed dreaming cron could not be reconciled (cron service unavailable).
2026-04-25T12:35:09-04:00 [plugins] memory-core: managed dreaming cron could not be reconciled (cron service unavailable).
2026-04-25T14:05:09-04:00 [plugins] memory-core: managed dreaming cron could not be reconciled (cron service unavailable).
2026-04-25T20:35:09-04:00 [plugins] memory-core: managed dreaming cron could not be reconciled (cron service unavailable).
2026-04-27T06:35:09-04:00 [plugins] memory-core: managed dreaming cron could not be reconciled (cron service unavailable).
... (continues at ~once-per-restart cadence)

Suggested fix directions

• (a) Defer until cron is ready — on params.reason === "startup", schedule a brief retry (e.g. 5s, capped at 30s) instead of warning. Only warn after the retry window expires with cron still unavailable.
• (b) Make the hook reentrant — let the first startup call return without warning when cron is unavailable; rely on the next heartbeat reconcile to do the work once cron is up. The dedup flag becomes a "we've seen this is missing, don't re-warn" rather than a "first call fails noisily."
• (c) Re-order startup — initialize the cron service before firing gateway:startup to plugin reconcile hooks. This may have broader implications for plugin ordering.

(a) and (b) are localized to dreaming-CDsj6KD1.js; (c) is more invasive.

Cross-reference

Same plugin (memory-core) as the sessions.delete admin-scope issue (Issue 2 / hotfix-6-issue-2-sessions-delete-admin-scope.md). Could be filed as a single ticket with two distinct sections if upstream prefers that grouping; filed separately here to keep the fix surfaces independent.