fix(memory-core): retry dreaming cron registration after startup deferral [AI-assisted]

[luyao618]

🤖 AI-assisted (built with Claude Code via Hermes orchestration). Test level: fully tested. Prompt summary available on request.

Summary

• Problem: The memory-core dreaming cron job fails to register at gateway startup due to a timing race — the gateway_start hook fires before the cron service is available. The runtime reconciliation path only triggers on heartbeat/cron events, creating a deadlock when the cron was never registered.
• Why it matters: The Memory Dreaming Promotion task never executes, breaking the dreaming feature entirely for affected users.
• What changed: Added a deferred retry (5-second setTimeout) after the startup deferral so the managed dreaming cron job registers once sidecars have settled.
• What did NOT change (scope boundary): No changes to core gateway code, no changes to the cron service lifecycle, no changes to the runtime reconciliation logic.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Plugin / extension

Linked Issue/PR

• Closes [Bug]: memory-core: dreaming cron never registers — startup timing + reconciliation skip bug #72841
• This PR fixes a bug or regression

Root Cause

• Root cause: The gateway_start hook fires via void hookRunner.runGatewayStart() (fire-and-forget) before sidecars fully start, so getCron() returns null. The existing runtime retry path in before_agent_reply only fires on heartbeat/cron triggers — if the dreaming cron never registered and no heartbeat fires, the reconciliation never runs, creating a deadlock.
• Missing detection / guardrail: No fallback mechanism to retry cron registration independent of incoming heartbeat/cron events.
• Contributing context: The fix for [Bug]: memory-core dreaming cron reconciliation depends on stale one-time startup cron reference — fails at runtime #67362 added runtime retry via gatewayContext.getCron() in before_agent_reply, but this path depends on heartbeat/cron triggers that may not fire if dreaming cron never registered.

Regression Test Plan

• Coverage level that should have caught this:
  • Unit test
• Target test or file: extensions/memory-core/src/dreaming.test.ts
• Scenario the test should lock in: When cron service is unavailable at startup but becomes available during the deferred retry window, the managed dreaming cron job is successfully registered.
• Why this is the smallest reliable guardrail: The unit test mocks the cron service availability timing and verifies the deferred retry path fires and succeeds.
• Existing test that already covers this (if any): N/A — existing tests only covered the startup success and runtime heartbeat-triggered reconciliation paths.

User-visible / Behavior Changes

• The Memory Dreaming Promotion cron job now registers successfully even when the cron service is briefly unavailable at gateway startup.

Diagram (if applicable)

N/A

Security Impact (required)

• New permissions/capabilities? No
• This fix adds a deferred retry timer within the existing memory-core plugin scope. No new permissions, no security surface changes, no credential handling.

[greptile-apps]

Greptile Summary

Adds a 5-second setTimeout deferred retry in the gateway_start handler so the managed dreaming cron job registers even when the cron service is unavailable at startup, breaking the deadlock described in #72841. Two regression tests cover the retry-success and retry-failure paths.

Confidence Score: 4/5

Safe to merge — the fix is narrowly scoped and the deferred retry is well-guarded by existing throttle logic.

No P0 or P1 findings. Single P2: the timer handle is not stored, preventing future cancellation. Throttle in reconcileManagedDreamingCron prevents double-registration. Tests cover both retry-success and retry-failure paths.

No files require special attention.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: extensions/memory-core/src/dreaming.ts
Line: 797-803

Comment:
**No handle stored for the deferred `setTimeout`**

The timer ID is discarded, so there is no way to cancel it if the gateway shuts down or the plugin is torn down within the 5-second window. This is harmless in production (it fires once and exits), but it can leave a dangling async operation in tests that don't advance the fake timers past the delay, and it prevents any future cleanup hook from cancelling it.

If a plugin-level teardown / `cleanup` hook exists, storing the handle and calling `clearTimeout(retryHandle)` there would be the complete fix.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(memory-core): retry dreaming cron re..." | Re-trigger Greptile}

[greptile-apps]

No handle stored for the deferred setTimeout

The timer ID is discarded, so there is no way to cancel it if the gateway shuts down or the plugin is torn down within the 5-second window. This is harmless in production (it fires once and exits), but it can leave a dangling async operation in tests that don't advance the fake timers past the delay, and it prevents any future cleanup hook from cancelling it.

If a plugin-level teardown / cleanup hook exists, storing the handle and calling clearTimeout(retryHandle) there would be the complete fix.

Prompt To Fix With AI

This is a comment left during a code review.
Path: extensions/memory-core/src/dreaming.ts
Line: 797-803

Comment:
**No handle stored for the deferred `setTimeout`**

The timer ID is discarded, so there is no way to cancel it if the gateway shuts down or the plugin is torn down within the 5-second window. This is harmless in production (it fires once and exits), but it can leave a dangling async operation in tests that don't advance the fake timers past the delay, and it prevents any future cleanup hook from cancelling it.

If a plugin-level teardown / `cleanup` hook exists, storing the handle and calling `clearTimeout(retryHandle)` there would be the complete fix.

How can I resolve this? If you propose a fix, please make it concise.

[clawsweeper]

Thanks for the context here. I swept through the related work, and this is now duplicate or superseded.

Current main already contains a more complete maintainer implementation of this PR's intended memory-core dreaming cron startup retry. The fix landed through merged PR #73493 as commit e84ebea, with bounded retries, timer cleanup, gateway_stop disposal, tests, and an Unreleased changelog entry for #72841.

Best possible solution:

Close this PR as superseded by the merged maintainer implementation in #73493. Keep the bounded retry and cleanup behavior already on main, and let the fix ship with the next OpenClaw release.

What I checked:

• Canonical merged fix: Commit e84ebea is fix(memory-core): retry dreaming cron startup reconciliation (#73493) and modified extensions/memory-core/src/dreaming.ts, its tests, and the changelog. (e84ebeafbd67)
• Current implementation: Current main has a bounded startup retry loop that schedules runtime cron reconciliation, stops after STARTUP_CRON_RETRY_MAX_ATTEMPTS, and triggers from gateway_start after startup reconciliation. (extensions/memory-core/src/dreaming.ts:820, f256eeba431b)
• Bot-review concern covered: The merged implementation stores startupCronRetryTimer, clears it through clearStartupCronRetry, and disposes it on gateway_stop, which addresses the open PR review concern about a discarded timeout handle. (extensions/memory-core/src/dreaming.ts:687, f256eeba431b)
• Regression tests: Tests now cover retrying until cron becomes available without heartbeat traffic, avoiding stale enabled config rescheduling after runtime config disables dreaming, and clearing a pending retry on gateway stop. (extensions/memory-core/src/dreaming.test.ts:1365, f256eeba431b)
• Changelog status: The changelog records the memory-core dreaming startup cron retry fix for [Bug]: memory-core: dreaming cron never registers — startup timing + reconciliation skip bug #72841 under Unreleased; git tag --contains e84ebeafbd67a420faf22c516562c67dc66b8e7c returned no tags, so no fixed release is identifiable yet. (CHANGELOG.md:25, f256eeba431b)
• Security review pass: The provided PR file list is limited to extensions/memory-core/src/dreaming.ts and extensions/memory-core/src/dreaming.test.ts; no workflows, dependency sources, lockfiles, install/build/release scripts, package metadata, secrets handling, or downloaded artifacts are touched. (68462d50c51a)

So I’m closing this here and keeping the remaining discussion on the canonical linked item.

Codex review notes: model gpt-5.5, reasoning high; reviewed against f256eeba431b; fix evidence: commit e84ebeafbd67.