openclaw - ✅(Solved) Fix Bug: memory-core logs 'cron service unavailable' on every gateway startup (2026.4.20) [4 pull requests, 2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#69939Fetched 2026-04-22 07:46:23
View on GitHub
Comments
2
Participants
2
Timeline
11
Reactions
0
Author
Participants
Timeline (top)
cross-referenced ×4referenced ×4commented ×2closed ×1

Root Cause

In dreaming-DA2EhSBZ.js, the reconcileManagedDreamingCron() function:

  1. Gets its cron reference from resolveCronServiceFromStartupSource(startupCronSource)
  2. startupCronSource is extracted from the gateway:startup hook event via resolveStartupCronSourceFromEvent(event)
  3. The startup event payload contains { cfg, deps, workspaceDir } where deps holds the cron service
  4. However, memory-core's startup hook fires before deps.cron is fully attached to the event context (the startup hook is deferred via a 250ms setTimeout in server.impl-DYBxSjUs.js:21272)
  5. As a result, source.context.cron ?? source.deps?.cron returns null on startup, triggering the warning

Once the cron service initializes and the flag unavailableCronWarningEmitted is reset (line 1478: if (cron) unavailableCronWarningEmitted = false), the warning stops.

PR fix notes

PR #69941: fix(memory-core): suppress startup "cron service unavailable" warning (closes #69939)

Description (problem / solution / changelog)

Closes #69939.

Bug

On every gateway startup, memory-core logs:

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

The warning fires once (guarded by unavailableCronWarningEmitted), but recurs on every cold/warm restart. The managed dreaming cron job itself runs correctly — this is purely a log-noise regression, not a functional failure.

Root cause

In src/plugins/core/server.impl the gateway:startup event is emitted via a deferred setTimeout (~250ms). deps.cron is not yet attached to the event context when memory-core's startup hook runs, so resolveCronServiceFromStartupSource(startupCronSource)source.context.cron ?? source.deps?.cron returns null on the first invocation. reconcileManagedDreamingCron() then emits the warning on the startup path, even though the cron service comes up seconds later and the runtime heartbeat reconciliation path successfully attaches the job.

Reporter's diagnosis and reproduction steps are in the issue (thanks @mlaihk).

Fix — Option A (minimally invasive)

In reconcileManagedDreamingCron(), only emit the warn when the function is called from the runtime reconciliation path (before_agent_reply heartbeat). On the startup path with cron == null, demote the message to logger.debug and leave the unavailableCronWarningEmitted flag unset so that if cron genuinely fails to initialize, the next runtime reconciliation still warns.

This preserves the existing "cron service is actually missing" signal — we only silence the known startup race.

Before

const cron = resolveCronServiceFromStartupSource(startupCronSource);
if (!cron && config.enabled && !unavailableCronWarningEmitted) {
  api.logger.warn(
    "memory-core: managed dreaming cron could not be reconciled (cron service unavailable).",
  );
  unavailableCronWarningEmitted = true;
}

After

const cron = resolveCronServiceFromStartupSource(startupCronSource);
if (!cron && config.enabled && !unavailableCronWarningEmitted) {
  // The gateway emits `gateway:startup` via a deferred setTimeout, and
  // `deps.cron` may not be attached yet when memory-core's startup hook fires
  // (see issue #69939). Avoid logging a confusing warning on the startup path —
  // the runtime reconciliation path (heartbeat-driven) will still warn if the
  // cron service remains unavailable after boot.
  if (params.reason === "startup") {
    api.logger.debug?.(
      "memory-core: cron service not yet available at gateway:startup; deferring to runtime reconciliation.",
    );
  } else {
    api.logger.warn(
      "memory-core: managed dreaming cron could not be reconciled (cron service unavailable).",
    );
    unavailableCronWarningEmitted = true;
  }
}

Considered but rejected:

  • Option B (track cronServiceSeen): more state for the same observable behavior.
  • Option C (reorder startup so deps.cron is attached before emitting gateway:startup): correct fix long-term, but touches server.impl and the core startup sequencer — out of scope for a log-noise patch. Worth tracking separately.

Tests

Added to extensions/memory-core/src/dreaming.test.ts:

  1. does not emit the cron-unavailable warning on gateway:startup when deps.cron is missing (regression #69939) — reproduces the issue: fires gateway:startup with deps: {}, asserts logger.warn is never called with "cron service unavailable", and asserts the debug message is logged instead.
  2. still warns on runtime reconciliation when cron remains unavailable (preserves #69939 genuine-failure signal) — fires startup with no cron (silent), then a heartbeat before_agent_reply with no cron, and asserts the warning does fire — ensuring the genuine reconciliation-failure signal is preserved.

Also added debug: vi.fn() to the existing createLogger() test helper to observe the downgraded log.

Test run

Full memory-core suite (test/vitest/vitest.extension-memory.config.ts):

Test Files  47 passed (47)
     Tests  496 passed | 3 skipped (499)

Scope

  • 2 files changed, 121 insertions, 4 deletions.
  • No changes to server.impl, the 250ms startup setTimeout, or the cron service itself.
  • No changes to dist/.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/memory-core/src/dreaming.test.ts (modified, +106/-0)
  • extensions/memory-core/src/dreaming.ts (modified, +15/-4)

PR #1: fix(memory-core): suppress false cron unavailable warning on startup

Description (problem / solution / changelog)

Summary

  • Suppresses the false "cron service unavailable" warning that fires on every gateway startup for 3-5 minutes
  • Root cause: reconcileManagedDreamingCron() fires on gateway:startup before deps.cron is attached (250ms deferred init race)
  • Fix: added params.reason !== "startup" guard so the warning only fires for genuine runtime unavailability

Test plan

  • Gateway starts with no false cron warning in logs
  • Warning still appears if cron is genuinely unavailable at runtime
  • Cron job runs on schedule as before
  • All existing tests pass: pnpm test

Fixes #69939

🤖 Generated with Claude Code

Changed files

  • extensions/memory-core/src/dreaming.ts (modified, +1/-1)

PR #69983: fix(memory-core): suppress false cron unavailable warning on startup

Description (problem / solution / changelog)

Summary

  • Suppresses the false "cron service unavailable" warning that fires on every gateway startup for 3-5 minutes
  • Root cause: reconcileManagedDreamingCron() fires on gateway:startup before deps.cron is attached (250ms deferred init race)
  • Fix: added params.reason !== "startup" guard so the warning only fires for genuine runtime unavailability

Test plan

  • Gateway starts with no false cron warning in logs
  • Warning still appears if cron is genuinely unavailable at runtime
  • Cron job runs on schedule as before
  • All existing tests pass: pnpm test

Fixes #69939

🤖 Generated with Claude Code

Changed files

  • README.md (modified, +294/-372)

PR #69644: Improve README with clearer instructions

Description (problem / solution / changelog)

I updated the README to make the setup process easier for beginners.

Added:

  • Clearer instructions
  • Common issues and fixes

This should help new users understand the project better.

Changed files

  • README.md (modified, +294/-372)
  • extensions/memory-core/src/dreaming.ts (modified, +1/-1)

Code Example

memory-core: managed dreaming cron could not be reconciled (cron service unavailable).
RAW_BUFFERClick to expand / collapse

Bug Description

On every gateway startup (including warm restarts), the memory-core plugin logs a warning:

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

This warning fires repeatedly for ~3-5 minutes after startup, then stops. The actual cron job (memory-core short-term promotion) runs on schedule normally — the warning is a timing artifact, not a functional failure.

Steps to Reproduce

  1. Start or restart the OpenClaw gateway (any version with memory-core enabled)
  2. Observe logs — warning fires within seconds of startup
  3. Warning recurs every ~30-60 seconds for several minutes, then stops
  4. cron list shows the Memory Dreaming Promotion job with status ok, running on schedule

Expected Behavior

No warning about cron service unavailability when the cron service is actually available and functioning.

Actual Behavior

Warning fires on startup, indicating cron object is null at the time memory-core's gateway:startup hook fires.

Root Cause

In dreaming-DA2EhSBZ.js, the reconcileManagedDreamingCron() function:

  1. Gets its cron reference from resolveCronServiceFromStartupSource(startupCronSource)
  2. startupCronSource is extracted from the gateway:startup hook event via resolveStartupCronSourceFromEvent(event)
  3. The startup event payload contains { cfg, deps, workspaceDir } where deps holds the cron service
  4. However, memory-core's startup hook fires before deps.cron is fully attached to the event context (the startup hook is deferred via a 250ms setTimeout in server.impl-DYBxSjUs.js:21272)
  5. As a result, source.context.cron ?? source.deps?.cron returns null on startup, triggering the warning

Once the cron service initializes and the flag unavailableCronWarningEmitted is reset (line 1478: if (cron) unavailableCronWarningEmitted = false), the warning stops.

Affected Version(s)

  • OpenClaw 2026.4.20 (likely earlier versions too)
  • memory-core plugin with dreaming.enabled = true

Code Location

  • dist/dreaming-DA2EhSBZ.js:1447unavailableCronWarningEmitted flag
  • dist/dreaming-DA2EhSBZ.js:1465-1478reconcileManagedDreamingCron() with warning logic
  • dist/dreaming-DA2EhSBZ.js:1493gateway:startup hook registration
  • dist/server.impl-DYBxSjUs.js:21272 — startup event emitted via 250ms setTimeout

Fix Suggestion

Either:

  1. Defer the startup reconciliation: Have memory-core skip or delay the cron availability check on startup, allowing the runtime reconciliation path to handle it once cron is initialized
  2. Attach cron earlier: Ensure deps.cron is fully attached before emitting the gateway:startup hook event
  3. Suppress duplicate warnings: The warning already only fires once (unavailableCronWarningEmitted guard) — the real issue is it fires at all when cron is genuinely available within seconds

Additional Context

The warning is harmless in that the cron job itself runs correctly. However, it:

  • Generates confusing startup logs
  • May trigger unnecessary monitoring alerts
  • Indicates a bug in startup hook ordering between memory-core and the cron service initialization

extent analysis

TL;DR

The most likely fix is to defer the startup reconciliation of the managed dreaming cron in the memory-core plugin, allowing the runtime reconciliation path to handle it once the cron service is initialized.

Guidance

  • Review the reconcileManagedDreamingCron() function in dreaming-DA2EhSBZ.js to understand how it retrieves the cron reference and how the unavailableCronWarningEmitted flag is used.
  • Consider implementing a delay or skip for the cron availability check on startup to prevent the warning from firing prematurely.
  • Investigate the startup event emission in server.impl-DYBxSjUs.js to see if the deps.cron attachment can be ensured before emitting the gateway:startup hook event.
  • Verify that the cron job runs correctly and on schedule after implementing any changes to ensure the fix does not introduce functional issues.

Example

No code snippet is provided as the issue does not require a specific code change, but rather a design or implementation adjustment.

Notes

The warning, although harmless, indicates a timing issue between the memory-core plugin's startup hook and the cron service initialization. The fix should focus on ensuring that the cron service is fully available before the memory-core plugin attempts to reconcile the managed dreaming cron.

Recommendation

Apply a workaround by deferring the startup reconciliation of the managed dreaming cron, as this approach directly addresses the timing issue without requiring significant changes to the existing codebase. This should help prevent the unnecessary warning from firing on startup.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Bug: memory-core logs 'cron service unavailable' on every gateway startup (2026.4.20) [4 pull requests, 2 comments, 2 participants]