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

• Repository: openclaw/openclaw
• Author: luyao618
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/73170

Description (problem / solution / changelog)

🤖 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 #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 #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.

Changed files

• extensions/memory-core/src/dreaming.test.ts (modified, +107/-0)
• extensions/memory-core/src/dreaming.ts (modified, +11/-0)