openclaw - ✅(Solved) Fix Bug: memory-core managed dreaming cron not recreated after gateway restart (silent failure) [1 pull requests, 1 participants]

richardmqq · 2026-04-09T22:09:26Z

[openclaw] plugins.entries.memory-core.config.dreaming.enabled = true with frequency: "0 3 " and timezone: "Asia/Shanghai" — memory-core creates the managed dr… `plugins.entries.memory-core.config.dreaming.enabled = true` with `frequency: "0 3 * * *"` and `timezone: "Asia/Shanghai"` — memory-core creates the managed dreaming cron job on first startup, but after any gateway restart or config reload, the cron is deleted and **never recreated**. No error is logged. # PR #63962: fix(gateway): include selected memory slot in startup plugin scope - Repository: openclaw/openclaw - Author: arifahmedjoy - State: closed | merged: False - Link: https://github.com/openclaw/openclaw/pull/63962 ## Description (problem / solution / changelog) ## Summary - Problem: gateway startup plugin selection did not explicitly include the selected memory-slot plugin when it was not also a configured channel plugin or startup sidecar. - Why it matters: memory-slot startup surfaces can be skipped, which can prevent memory-driven startup reconciliation behaviors from running reliably. - What changed: `resolveGatewayStartupPluginIds` now includes the selected memory-slot plugin when activation state permits it. - What did NOT change: no cron execution internals, no plugin runtime API changes, no config schema changes. ## Change Type (select all) - [x] Bug fix - [ ] Feature - [ ] Refactor required for the fix - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [x] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [x] Memory / storage - [ ] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes # - Related #63936 - [x] This PR fixes a bug or regression ## Root Cause (if applicable) - Root cause: startup plugin ID resolution only included configured channel plugins plus startup sidecars; the selected memory-slot plugin can fall outside both sets. - Missing detection / guardrail: no startup invariant test that asserted selected memory slot plugin inclusion. - Contributing context (if known): related reports (#62920, #63465) show the same symptom family; #63097 addresses overlapping startup reconciliation behavior. ## Regression Test Plan (if applicable) - Coverage level that should have caught this: - [x] Unit test - [ ] Seam / integration test - [ ] End-to-end test - [ ] Existing coverage already sufficient - Target test or file: `src/plugins/channel-plugin-ids.test.ts` - Scenario the test should lock in: - default startup includes `memory-core` when selected in memory slot - custom memory slot selection includes only the selected memory plugin in startup IDs - restrictive allowlist expectations still include the selected memory-slot plugin - Why this is the smallest reliable guardrail: the bug is in startup plugin-ID classification, fully exercised by resolver unit tests. - Existing test that already covers this (if any): existing startup resolver table tests now extended. - If no new test is added, why not: N/A ## User-visible / Behavior Changes - Gateway startup now consistently includes the selected memory-slot plugin in startup plugin scope. ## Diagram (if applicable) ```text Before: [gateway startup] -> [resolve startup plugin IDs] -> [memory-slot plugin may be excluded] -> [memory startup reconciliation may not run] After: [gateway startup] -> [resolve startup plugin IDs] -> [selected memory-slot plugin included] -> [memory startup reconciliation path available] ``` ## Security Impact (required) - New permissions/capabilities? No - Secrets/tokens handling changed? No - New/changed network calls? No - Command/tool execution surface changed? No - Data access scope changed? No - If any `Yes`, explain risk + mitigation: N/A ## Repro + Verification ### Environment - OS: Windows (dev), issue reports from macOS/Linux environments - Runtime/container: Node + pnpm workspace - Model/provider: N/A - Integration/channel (if any): N/A - Relevant config (redacted): default and custom `plugins.slots.memory` ### Steps 1. Select memory slot plugin in config (`memory-core` default or custom memory plugin). 2. Resolve gateway startup plugin IDs. 3. Verify selected memory-slot plugin is present in startup scope. ### Expected - selected memory-slot plugin is included in startup plugin IDs. ### Actual - verified by focused tests in `src/plugins/channel-plugin-ids.test.ts`. ## Evidence - [x] Failing test/log before + passing after - [ ] Trace/log snippets - [ ] Screenshot/recording - [ ] Perf numbers (if relevant) ## Human Verification (required) - Verified scenarios: ran `pnpm test -- src/plugins/channel-plugin-ids.test.ts` and confirmed all resolver scenarios pass with the new memory-slot startup invariant. - Edge cases checked: restrictive allowlist startup case, custom memory slot selection, default startup path. - What you did **not** verify: full end-to-end gateway restart reproduction on a live memory-core installation. ## Review Conversations

openclaw2026-04-09 22:09:26

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.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#63936•Fetched 2026-04-10 03:41:34

View on GitHub

Comments

Participants

Timeline

Reactions

Author

richardmqq

Participants

richardmqq

Timeline (top)

cross-referenced ×1

plugins.entries.memory-core.config.dreaming.enabled = true with frequency: "0 3 * * *" and timezone: "Asia/Shanghai" — memory-core creates the managed dreaming cron job on first startup, but after any gateway restart or config reload, the cron is deleted and never recreated. No error is logged.

Error Message

Root Cause

Hypothesis: The startup hook is registered but either:

The gateway:startup event is not delivered to memory-core's hook after restart (timing/ordering issue with 8 plugins vs 7)
resolveCronServiceFromStartupEvent returns null because the cron service is not yet available in the event context at hook execution time
The reconciliation runs but silently returns early without logging

Fix Action

Workaround

Manually creating the exact managed job works:

openclaw cron add \
  --name "Memory Dreaming Promotion" \
  --cron "0 3 * * *" \
  --tz "Asia/Shanghai" \
  --agent main \
  --system-event "__openclaw_memory_core_short_term_promotion_dream__" \
  --description "[managed-by=memory-core.short-term-promotion] Manual workaround"

PR fix notes

PR #63962: fix(gateway): include selected memory slot in startup plugin scope

Repository: openclaw/openclaw
Author: arifahmedjoy
State: closed | merged: False
Link: https://github.com/openclaw/openclaw/pull/63962

Description (problem / solution / changelog)

Summary

Problem: gateway startup plugin selection did not explicitly include the selected memory-slot plugin when it was not also a configured channel plugin or startup sidecar.
Why it matters: memory-slot startup surfaces can be skipped, which can prevent memory-driven startup reconciliation behaviors from running reliably.
What changed: resolveGatewayStartupPluginIds now includes the selected memory-slot plugin when activation state permits it.
What did NOT change: no cron execution internals, no plugin runtime API changes, no config schema changes.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes #
Related #63936
This PR fixes a bug or regression

Root Cause (if applicable)

Root cause: startup plugin ID resolution only included configured channel plugins plus startup sidecars; the selected memory-slot plugin can fall outside both sets.
Missing detection / guardrail: no startup invariant test that asserted selected memory slot plugin inclusion.
Contributing context (if known): related reports (#62920, #63465) show the same symptom family; #63097 addresses overlapping startup reconciliation behavior.

Regression Test Plan (if applicable)

Coverage level that should have caught this:
- Unit test
- Seam / integration test
- End-to-end test
- Existing coverage already sufficient
Target test or file: src/plugins/channel-plugin-ids.test.ts
Scenario the test should lock in:
- default startup includes memory-core when selected in memory slot
- custom memory slot selection includes only the selected memory plugin in startup IDs
- restrictive allowlist expectations still include the selected memory-slot plugin
Why this is the smallest reliable guardrail: the bug is in startup plugin-ID classification, fully exercised by resolver unit tests.
Existing test that already covers this (if any): existing startup resolver table tests now extended.
If no new test is added, why not: N/A

User-visible / Behavior Changes

Gateway startup now consistently includes the selected memory-slot plugin in startup plugin scope.

Diagram (if applicable)

Before:
[gateway startup] -> [resolve startup plugin IDs]
                -> [memory-slot plugin may be excluded]
                -> [memory startup reconciliation may not run]

After:
[gateway startup] -> [resolve startup plugin IDs]
                -> [selected memory-slot plugin included]
                -> [memory startup reconciliation path available]

Security Impact (required)

New permissions/capabilities? No
Secrets/tokens handling changed? No
New/changed network calls? No
Command/tool execution surface changed? No
Data access scope changed? No
If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

OS: Windows (dev), issue reports from macOS/Linux environments
Runtime/container: Node + pnpm workspace
Model/provider: N/A
Integration/channel (if any): N/A
Relevant config (redacted): default and custom plugins.slots.memory

Steps

Select memory slot plugin in config (memory-core default or custom memory plugin).
Resolve gateway startup plugin IDs.
Verify selected memory-slot plugin is present in startup scope.

Expected

selected memory-slot plugin is included in startup plugin IDs.

Actual

verified by focused tests in src/plugins/channel-plugin-ids.test.ts.

Evidence

Failing test/log before + passing after
Trace/log snippets
Screenshot/recording
Perf numbers (if relevant)

Human Verification (required)

Verified scenarios: ran pnpm test -- src/plugins/channel-plugin-ids.test.ts and confirmed all resolver scenarios pass with the new memory-slot startup invariant.
Edge cases checked: restrictive allowlist startup case, custom memory slot selection, default startup path.
What you did not verify: full end-to-end gateway restart reproduction on a live memory-core installation.

Review Conversations

I replied to or resolved every bot review conversation I addressed in this PR.
I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

Backward compatible? Yes
Config/env changes? No
Migration needed? No
If yes, exact upgrade steps: N/A

Risks and Mitigations

Risk: could load one additional plugin at startup in setups where memory slot is selected but previously omitted.
- Mitigation: startup inclusion is constrained to selected memory slot plugin and existing activation-state checks.
Risk: overlap with #63097 implementation details.
- Mitigation: this PR remains narrowly scoped to startup plugin ID classification and has focused regression tests.

Changed files

src/commands/doctor-bootstrap-size.test.ts (modified, +1/-0)
src/plugins/channel-plugin-ids.test.ts (modified, +68/-6)
src/plugins/channel-plugin-ids.ts (modified, +18/-0)

Code Example

{
  "plugins": {
    "entries": {
      "memory-core": {
        "config": {
          "dreaming": {
            "enabled": true,
            "frequency": "0 3 * * *",
            "timezone": "Asia/Shanghai",
            "verboseLogging": true
          }
        }
      }
    }
  }
}

---

openclaw cron add \
  --name "Memory Dreaming Promotion" \
  --cron "0 3 * * *" \
  --tz "Asia/Shanghai" \
  --agent main \
  --system-event "__openclaw_memory_core_short_term_promotion_dream__" \
  --description "[managed-by=memory-core.short-term-promotion] Manual workaround"

RAW_BUFFERClick to expand / collapse

Summary

Environment

OpenClaw: 2026.4.9 (0512059)
OS: macOS 15.7.3 (Darwin 24.6.0, arm64)
Node: v25.7.0
Installation: Homebrew

Config

{
  "plugins": {
    "entries": {
      "memory-core": {
        "config": {
          "dreaming": {
            "enabled": true,
            "frequency": "0 3 * * *",
            "timezone": "Asia/Shanghai",
            "verboseLogging": true
          }
        }
      }
    }
  }
}

Timeline (observed on our instance)

2026-04-08T22:04:12+08:00 — memory-core: created managed dreaming cron job. ✅ (first startup after enabling)
2026-04-09T15:17:xx+08:00 — Gateway receives SIGTERM
2026-04-09T15:18:38+08:00 — memory-core: removed 1 managed dreaming cron job(s).
2026-04-09T15:18:37+08:00 — Gateway restarts successfully (ready (8 plugins, 0.4s))
No created managed dreaming cron job log ever appears again — across 6+ subsequent restarts
openclaw cron list shows zero dreaming jobs
No errors in gateway.err.log related to dreaming or memory-core

Source-level investigation

Traced through the code:

registerShortTermPromotionDreaming(api) in memory-core/index.js:682 registers the gateway:startup hook
reconcileShortTermDreamingCronJob should check for existing managed jobs and recreate if config.enabled && managed.length === 0
resolveCronServiceFromStartupEvent(event) extracts the cron service from event.context.deps.cron
Config resolves correctly: normalizeBoolean(true, false) → true, frequency and timezone parse fine

Hypothesis: The startup hook is registered but either:

The gateway:startup event is not delivered to memory-core's hook after restart (timing/ordering issue with 8 plugins vs 7)
resolveCronServiceFromStartupEvent returns null because the cron service is not yet available in the event context at hook execution time
The reconciliation runs but silently returns early without logging

The fact that it worked once (7 plugins, 0.5s startup) but never again (8 plugins, 0.4s startup) suggests a race condition or plugin load order issue.

Workaround

Manually creating the exact managed job works:

openclaw cron add \
  --name "Memory Dreaming Promotion" \
  --cron "0 3 * * *" \
  --tz "Asia/Shanghai" \
  --agent main \
  --system-event "__openclaw_memory_core_short_term_promotion_dream__" \
  --description "[managed-by=memory-core.short-term-promotion] Manual workaround"

Related issues

#62920 — same symptom reported on 2026.4.5
#63465 — same symptom, different reporter

All three reports share the pattern: cron created once → deleted on shutdown/reload → never recreated.

extent analysis

TL;DR

The issue can be temporarily worked around by manually creating the managed dreaming cron job using the openclaw cron add command.

Guidance

Investigate the plugin load order and timing to identify potential race conditions that may prevent the gateway:startup event from being delivered to memory-core's hook after restart.
Verify that the resolveCronServiceFromStartupEvent function is returning a valid cron service instance, and that the reconcileShortTermDreamingCronJob function is being executed correctly.
Consider adding logging statements to the reconcileShortTermDreamingCronJob function to determine if it is silently returning early without logging.
Review the code changes between OpenClaw versions 2026.4.5 and 2026.4.9 to see if any changes may have introduced the issue.

Example

openclaw cron add \
  --name "Memory Dreaming Promotion" \
  --cron "0 3 * * *" \
  --tz "Asia/Shanghai" \
  --agent main \
  --system-event "__openclaw_memory_core_short_term_promotion_dream__" \
  --description "[managed-by=memory-core.short-term-promotion] Manual workaround"

Notes

The issue appears to be related to a race condition or plugin load order issue, and may require changes to the memory-core plugin or the OpenClaw framework to resolve.

Recommendation

Apply the manual workaround using the openclaw cron add command until a permanent fix can be implemented, as it allows the managed dreaming cron job to be created and functional.

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?

#api #installation #agent execution #callback error #memory management

Still need to ship something?

×6

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

openclaw - ✅(Solved) Fix Bug: memory-core managed dreaming cron not recreated after gateway restart (silent failure) [1 pull requests, 1 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Fix Action

Workaround

PR fix notes

PR #63962: fix(gateway): include selected memory slot in startup plugin scope

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Root Cause (if applicable)

Regression Test Plan (if applicable)

User-visible / Behavior Changes

Diagram (if applicable)

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Risks and Mitigations

Changed files

Code Example

Summary

Environment

Config

Timeline (observed on our instance)

Source-level investigation

Workaround

Related issues

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

Still need to ship something?

RELATED_DISCOVERY

TRENDING