openclaw - ✅(Solved) Fix [Bug]: Cron: Isolated sessions not executing [1 pull requests, 1 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#52806Fetched 2026-04-08 01:19:06
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
Timeline (top)
labeled ×2commented ×1cross-referenced ×1

Cron jobs with sessionTarget: "isolated" are not executing. Manual trigger via cron run returns enqueued: true but no session is created and no run records appear in cron runs.

Error Message

Changed to sessionTarget: "main" (different error)

Root Cause

Cron jobs with sessionTarget: "isolated" are not executing. Manual trigger via cron run returns enqueued: true but no session is created and no run records appear in cron runs.

Fix Action

Fix / Workaround

Attempted fixes (all failed): Disabled/re-enabled job Deleted and recreated job Removed wakeMode parameter Changed to sessionTarget: "main" (different error) Gateway restart Multiple manual triggers Workaround: Using manual execution - user requests "执行日报" which triggers direct tool calls instead of cron.

PR fix notes

PR #52815: fix(cron): correct timezone rollback bug for Asia/Shanghai and fix st…

Description (problem / solution / changelog)

Closes #52806

Summary

  • Problem: Cron jobs with sessionTarget: isolated and tz: Asia/Shanghai never execute — timer fires at wrong time, and manual cron run returns enqueued: true but creates no session.
  • Why it matters: Blocks all scheduled automation (daily reports, alerts) for any job using a UTC+ timezone. 100% failure rate.
  • What changed: (1) schedule.ts — changed setUTCHourssetHours in the croner timezone rollback so the retry cursor uses local midnight, not UTC midnight. (2) ops.ts — added targeted nextRunAtMs recompute for the specific job when mode === force, so stale timestamps don't silently block execution.
  • What did NOT change: Timer tick logic, other session targets, delivery, run log writing — all untouched.

Change Type

  • Bug fix

Scope

  • Gateway / orchestration

Linked Issue

  • Closes #52806

User-visible Changes

  • Jobs with tz: Asia/Shanghai (and UTC+ zones) now compute correct nextAt
  • Manual cron run --jobId <id> now actually executes instead of silently skipping

Security Impact

  • 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

Repro

  1. Create cron job: sessionTarget: isolated, payload.kind: agentTurn, tz: Asia/Shanghai, expr: 0 12 * * *
  2. Check nextAt — shows 04:00 UTC instead of 12:00 CST
  3. Run cron run --jobId <id> — returns enqueued: true but no session created
  4. After fix: correct nextAt, session created, cron runs shows execution record

Evidence

  • Reporter logs in #52806 confirm nextAt: 1774245600000, clamped: true, empty cron runs

Human Verification

  • Verified correct nextAt for Asia/Shanghai after fix
  • Verified cron run --force executes and creates session
  • Jobs with correct timestamps unaffected
  • Did NOT verify: full matrix of UTC+ timezones, concurrent force-run edge cases

Compatibility

  • Backward compatible? Yes
  • Migration needed? No

Failure Recovery

  • Revert: git revert <sha> — changes are isolated to two small functions
  • Watch for: rapid repeated cron: timer armed log entries (would indicate recompute loop)

Risks

  • setHours uses server local timezone for the retry cursor, not the job's tz. Low risk — croner still handles final timezone math using the job's tz field directly.

Changed files

  • src/cron/schedule.ts (modified, +3/-2)
  • src/cron/service/ops.ts (modified, +9/-0)

Code Example

# Timer is armed but never fires
{"module":"cron","storePath":"/home/gem/workspace/agent/cron/jobs.json"}
{"nextAt":1774245600000,"delayMs":60000,"clamped":true}
"cron: timer armed"

# Manual trigger returns success but no execution
> cron run --jobId f71bf7ff-5648-4478-a942-c4a1226f8210
{ "ok": true, "enqueued": true, "runId": "manual:..." }

# But cron runs is empty
> cron runs --jobId f71bf7ff-5648-4478-a942-c4a1226f8210
{ "entries": [], "total": 0 }

# No isolated session created
> sessions_list
{ "count": 0, "sessions": [] }
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Summary

Cron jobs with sessionTarget: "isolated" are not executing. Manual trigger via cron run returns enqueued: true but no session is created and no run records appear in cron runs.

Steps to reproduce

Create a cron job with sessionTarget: "isolated" and payload.kind: "agentTurn"

{ "name": "test-job", "schedule": { "expr": "0 12 * * *", "kind": "cron", "tz": "Asia/Shanghai" }, "sessionTarget": "isolated", "payload": { "kind": "agentTurn", "message": "test" } } Trigger manually via cron run API

Observe: API returns { "ok": true, "enqueued": true } but no session is created

Check cron runs - entries are always empty

Expected behavior

Cron job should create an isolated session and execute cron runs should show execution records Timer should fire at scheduled time

Actual behavior

cron run returns enqueued: true but no session created cron runs returns empty entries [] Timer logs show cron: timer armed but no cron: timer fired nextAt calculation appears wrong (e.g., 0 12 * * * shows nextAt = 04:00 instead of 12:00)

OpenClaw version

Latest (npm install -g openclaw@latest)

Operating system

Linux 6.8.0-100-generic (Ubuntu-based)

Install method

npm global

Model

miaoda/miaoda-model-auto

Provider / routing chain

openclaw -> miaoda

Additional provider/model setup details

Using Feishu (飞书) channel for messaging. Cron jobs configured to read Feishu group messages and generate daily reports.

Logs, screenshots, and evidence

# Timer is armed but never fires
{"module":"cron","storePath":"/home/gem/workspace/agent/cron/jobs.json"}
{"nextAt":1774245600000,"delayMs":60000,"clamped":true}
"cron: timer armed"

# Manual trigger returns success but no execution
> cron run --jobId f71bf7ff-5648-4478-a942-c4a1226f8210
{ "ok": true, "enqueued": true, "runId": "manual:..." }

# But cron runs is empty
> cron runs --jobId f71bf7ff-5648-4478-a942-c4a1226f8210
{ "entries": [], "total": 0 }

# No isolated session created
> sessions_list
{ "count": 0, "sessions": [] }

Impact and severity

Affected: All cron jobs with isolated session target Severity: High (blocks scheduled automation workflows) Frequency: 100% - Always fails for affected jobs Consequence: Cannot use cron for automated tasks like daily reports, pharma news alerts

Additional information

Attempted fixes (all failed): Disabled/re-enabled job Deleted and recreated job Removed wakeMode parameter Changed to sessionTarget: "main" (different error) Gateway restart Multiple manual triggers Workaround: Using manual execution - user requests "执行日报" which triggers direct tool calls instead of cron.

Evidence that isolated sessions CAN work: The job lobster-daily-report (Job ID: 723d3ba3-e912-4956-b215-3dfbdd3b6b4d) with identical configuration (isolated + agentTurn) DOES execute successfully at 12:00 daily. This suggests a race condition or state corruption issue affecting other jobs.

extent analysis

Fix Plan

To resolve the issue with cron jobs not executing when sessionTarget is set to "isolated", follow these steps:

  1. Verify Cron Job Configuration: Ensure that the cron job configuration is correct, especially the schedule and sessionTarget fields.
  2. Check Timezone Settings: Confirm that the timezone setting (tz) in the cron job configuration matches the system's timezone.
  3. Update OpenClaw Configuration: Update the OpenClaw configuration to handle isolated sessions correctly. Add the following code to the OpenClaw configuration file:
// openclaw.config.js
module.exports = {
  // ... other configurations ...
  cron: {
    // ... other cron configurations ...
    isolatedSessionTimeout: 30000, // 30 seconds
  },
};
  1. Implement Retry Mechanism: Implement a retry mechanism for cron jobs that fail to execute due to isolated session issues. Add the following code to the cron job execution handler:
// cron.job.js
const maxRetries = 3;
const retryDelay = 5000; // 5 seconds

async function executeCronJob(job) {
  let retries = 0;
  while (retries < maxRetries) {
    try {
      // Execute the cron job
      await executeJob(job);
      break;
    } catch (error) {
      retries++;
      console.error(`Error executing cron job: ${error.message}`);
      await new Promise((resolve) => setTimeout(resolve, retryDelay));
    }
  }
}
  1. Update Cron Job Payload: Update the cron job payload to include a unique identifier for the isolated session. Add the following code to the cron job payload:
{
  "name": "test-job",
  "schedule": { "expr": "0 12 * * *", "kind": "cron", "tz": "Asia/Shanghai" },
  "sessionTarget": "isolated",
  "payload": {
    "kind": "agentTurn",
    "message": "test",
    "sessionId": "unique-session-id"
  }
}

Verification

To verify that the fix worked:

  1. Trigger the cron job manually using the cron run command.
  2. Check the cron runs log to ensure that the job executed successfully.
  3. Verify that an isolated session was created by checking the sessions list.

Extra Tips

  • Ensure that the system's timezone is set correctly to avoid issues with cron job scheduling.
  • Monitor the cron job execution logs to detect any issues with isolated sessions.
  • Consider implementing additional logging and monitoring to detect and resolve issues with cron job execution.

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…

FAQ

Expected behavior

Cron job should create an isolated session and execute cron runs should show execution records Timer should fire at scheduled time

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]: Cron: Isolated sessions not executing [1 pull requests, 1 comments, 2 participants]