openclaw - 💡(How to fix) Fix [Bug]: PR #71694 runtime cron service fallback ineffective on Linux v2026.4.25 — `gatewayContext.getCron()` returns null [1 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

PR #71694 ("fix(memory-core): add runtime cron service fallback for dreaming reconciliation", merged 2026-04-25) intends to recover the dreaming cron reconciliation when the startup capture is null by falling back to resolveCronServiceFromGatewayContext(gatewayContext). On a fresh Linux Debian 11 install of v2026.4.25, both layers return null and the warning still fires:

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

The new unavailableCronWarningEmitted flag correctly limits emissions to one per gateway lifetime (vs. v4.23's hourly XX:46 cadence), which is an improvement in noise, but the underlying cron registration still does not succeed — managed scheduler dispatch at the configured 0 3 * * * daily fire never runs in production. Manual openclaw cron run <jobId> continues to work because that path bypasses the scheduler binding.

Steps to reproduce

1. npm install -g [email protected] --ignore-scripts on Debian 11 (Node 24.13.0, NVM)
2. Run base npm install --omit=dev --ignore-scripts --legacy-peer-deps and the eager bundled-plugin postinstall (OPENCLAW_EAGER_BUNDLED_PLUGIN_DEPS=1 node scripts/postinstall-bundled-plugins.mjs)
3. Restart openclaw-gateway.service (user systemd)
4. Wait ≥5 minutes
5. grep -c 'cron service unavailable' /tmp/openclaw/openclaw-$(date +%Y-%m-%d).log

Expected behavior

After PR #71694, state.deps.cron is captured at runtime via gatewayContext.getCron() if startup capture missed it. Warning should not fire, and the scheduler should dispatch the configured daily cron.

Actual behavior

Warning fires once at ~5min post-restart. End-to-end dreaming via openclaw cron run <id> works (light/rem/deep all complete, events.jsonl shows memory.dream.completed for all phases); but the upstream scheduler never dispatches the configured 0 3 * * * Asia/Taipei job — observable by openclaw cron list showing Status: skipped, Last: 18h ago even after manual triggers succeed.

Source-level evidence

The warning emission is at dist/dreaming-CdZwJUa6.js:1536. Looking at the runtime fallback path (lines 1517–1545):

const reconcileManagedDreamingCron = async (params) => {
    // ...
    if (params.reason === "startup") resolveStartupCron = params.startupCron ?? null;
    let cron = resolveStartupCron?.() ?? null;
    if (!cron && params.reason === "runtime" && gatewayContext) try {
        cron = resolveCronServiceFromGatewayContext(gatewayContext);
        if (cron) resolveStartupCron = () => cron;
    } catch {}
    // ...
    if (!cron && config.enabled && !unavailableCronWarningEmitted) {
        // ...
        api.logger.warn("memory-core: managed dreaming cron could not be reconciled (cron service unavailable).");
        unavailableCronWarningEmitted = true;
    }
}

resolveCronServiceFromGatewayContext at line 1266 simply does:

function resolveCronServiceFromGatewayContext(context) {
    return resolveCronServiceFromCandidate(context?.getCron?.());
}

In our deployment, context.getCron() returns null (gatewayContext is set non-null at line 1555 — gatewayContext = ctx — but its .getCron() produces null). So both fallbacks fail. The deeper question is why context.getCron does not return a real cron service handle at runtime on Linux.

Environment

Workaround in place

A system crontab entry at 55 14 * * * UTC (22:55 Asia/Taipei) calls openclaw cron run <jobId> directly, bypassing the broken scheduler binding. This has been operational since 2026-04-17 across v4.15 → v4.20 → v4.22 → v4.23 → v4.25.

Related

• #67362 (closed by #71694)
• #71694 (the merged fix)
• #71737 (RFC: scheduler lifecycle)