Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Feature]: Cron scheduler should reload jobs.json after startup (fs.watch or periodic re-read) [1 pull requests, 4 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#52772•Fetched 2026-04-08 01:19:39
View on GitHub
Comments
4
Participants
2
Timeline
20
Reactions
0
Author
mossaemossae
Participants
ArtyomkunArtyomkunmossaemossae
Timeline (top)
mentioned ×7subscribed ×7commented ×4cross-referenced ×1

Cron scheduler loads jobs.json once at startup and never re-reads it, making runtime job additions invisible without a gateway restart.

Error Message

When the CLI's RPC channel to the gateway is unavailable (e.g. due to the handshake timeout bug), the only workaround is writing directly to ~/.openclaw/cron/jobs.json. However, the running scheduler never picks up these changes - it loaded the file once at startup with 0 jobs and never checks again. This means cron jobs written after startup silently never fire, with no error or warning to the user.

Root Cause

Cron scheduler loads jobs.json once at startup and never re-reads it, making runtime job additions invisible without a gateway restart.

Fix Action

Fix / Workaround

When the CLI's RPC channel to the gateway is unavailable (e.g. due to the handshake timeout bug), the only workaround is writing directly to ~/.openclaw/cron/jobs.json. However, the running scheduler never picks up these changes - it loaded the file once at startup with 0 jobs and never checks again. This means cron jobs written after startup silently never fire, with no error or warning to the user.

Affected: Any user whose CLI->gateway RPC is unavailable; also affects scripted/external tools that write to jobs.json directly Severity: Blocks workflow ->written jobs silently never execute Frequency: Always reproducible when writing to the file after gateway startup Consequence: Cron/reminder functionality completely fails with no feedback; users have no reliable workaround

PR fix notes

PR #53528: feat: watch jobs.json for external changes to invalidate store cache

Description (problem / solution / changelog)

Summary

• Problem: The cron scheduler never picks up jobs written directly to jobs.json after startup — the in-memory store is only reloaded on timer ticks (up to 60s later), so external writes are silently ignored. • Why it matters: Direct file writes are the only workaround when CLI RPC is unavailable (e.g. during the gateway handshake bug). Without this fix, those writes are useless. • What changed: Added fs.watch on jobs.json so external writes immediately invalidate the in-memory store cache, triggering a reload on the next timer tick. • What did NOT change: Job scheduling logic, timer behavior, persistence, and all existing reload paths are untouched.

Change Type

• [ ] Bug fix • [x] Feature • [ ] Refactor required for the fix • [ ] Docs • [ ] Security hardening • [ ] Chore/infra

Scope

• [ ] Gateway / orchestration • [ ] Skills / tool execution • [ ] Auth / tokens • [x] Memory / storage • [ ] Integrations • [ ] API / contracts • [ ] UI / DX • [ ] CI/CD / infra

Linked Issue/PR

• Closes #[52772] • Related #[52766] • [ ] This PR fixes a bug or regression

Root Cause / Regression History

N/A — this is a new feature, not a regression.

Regression Test Plan

N/A

User-visible / Behavior Changes

Jobs written directly to jobs.json are now picked up within seconds rather than waiting up to 60s for the next timer tick.

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 + Verification

Environment

• OS: Linux 6.8.0 (x64) • Runtime/container: Non-systemd, gateway running in foreground • Integration/channel: Telegram • Relevant config: gateway.mode=local, gateway.bind=loopback

Steps

  1. Start the gateway
  2. Write a valid job directly to ~/.openclaw/cron/jobs.json
  3. Wait for scheduler to pick it up

Expected

Job is picked up immediately when fs.watch fires, or within 60s as fallback

Actual (before fix)

Job is never picked up — in-memory store is never invalidated

Evidence

Gateway logs before fix showed the scheduler never reloading after a file write:

[INFO] {"module":"cron"} { enabled: true, jobs: 0, nextWakeAtMs: null } [INFO] {"module":"cron"} { enabled: true, jobs: 0, nextWakeAtMs: null } jobs.json was updated between these two log lines — confirming state.store was never invalidated.

Human Verification

• Verified: fs.watch callback fires on file write → state.store is nulled → timer re-arms • Edge cases checked: fs.watch error handler fires silently; cleanup runs on stop() • Not verified: Behavior on NFS or Windows filesystems

Compatibility / Migration

• Backward compatible? Yes • Config/env changes? No • Migration needed? No

Failure Recovery

• How to revert: Revert the 3 changed files • Files to restore: • src/cron/service/state.ts • src/cron/service/store.ts • src/cron/service/ops.ts • Known bad symptoms: None expected — fs.watch errors are caught and fall back silently

Risks and Mitigations

• Risk: fs.watch may fire spuriously on some filesystems, causing unnecessary store invalidations • Mitigation: Invalidation only nulls the in-memory cache — the reload on next tick is the normal code path, so spurious fires are harmless fixes #52772

Changed files

  • src/cron/service.test-harness.ts (modified, +1/-0)
  • src/cron/service/ops.ts (modified, +4/-1)
  • src/cron/service/state.ts (modified, +2/-0)
  • src/cron/service/store.ts (modified, +40/-0)
RAW_BUFFERClick to expand / collapse

Summary

Cron scheduler loads jobs.json once at startup and never re-reads it, making runtime job additions invisible without a gateway restart.

Problem to solve

When the CLI's RPC channel to the gateway is unavailable (e.g. due to the handshake timeout bug), the only workaround is writing directly to ~/.openclaw/cron/jobs.json. However, the running scheduler never picks up these changes - it loaded the file once at startup with 0 jobs and never checks again. This means cron jobs written after startup silently never fire, with no error or warning to the user.

Proposed solution

Add file watching to the cron scheduler using fs.watch or fs.watchFile on jobs.json. When a change is detected, reload the job list and reschedule accordingly. As a fallback for environments where file watching is unreliable, a periodic re-read interval (e.g. every 30s) would also suffice.

Alternatives considered

Restarting the gateway to force a reload works but is disruptive and not viable for production setups. Manual RPC via CLI is the intended path but is blocked by a separate handshake bug (see related issue).

Impact

Affected: Any user whose CLI->gateway RPC is unavailable; also affects scripted/external tools that write to jobs.json directly Severity: Blocks workflow ->written jobs silently never execute Frequency: Always reproducible when writing to the file after gateway startup Consequence: Cron/reminder functionality completely fails with no feedback; users have no reliable workaround

Evidence/examples

Gateway logs confirm single load at startup, no subsequent reload:

[19:17] [INFO] {"module":"cron"} { enabled: true, jobs: 0, nextWakeAtMs: null } [19:49] [INFO] {"module":"cron"} { enabled: true, jobs: 0, nextWakeAtMs: null }

Job written to file between these two timestamps - never fired.

Additional information

Should remain backward-compatible. File watching should degrade gracefully in environments where fs.watch is unreliable (some containers/network filesystems). Related bug: gateway WebSocket handshake timeout (issue #52766 )

extent analysis

Fix Plan

To address the issue of the cron scheduler not reloading the jobs.json file after startup, we will implement file watching using fs.watch and a periodic re-read interval as a fallback.

Step-by-Step Solution:

  1. Import required modules: Use fs and fs.watch to monitor file changes.
  2. Set up file watching: Create a watcher for the jobs.json file.
  3. Handle file changes: When a change is detected, reload the job list and reschedule accordingly.
  4. Implement periodic re-read: As a fallback, periodically re-read the jobs.json file (e.g., every 30 seconds).

Example Code:

const fs = require('fs');
const cron = require('cron');

// Set up file watching
fs.watch('~/.openclaw/cron/jobs.json', (eventType, filename) => {
  if (eventType === 'change') {
    // Reload job list and reschedule
    reloadJobs();
  }
});

// Periodic re-read interval (fallback)
setInterval(() => {
  reloadJobs();
}, 30000); // 30 seconds

// Reload job list function
function reloadJobs() {
  fs.readFile('~/.openclaw/cron/jobs.json', (err, data) => {
    if (err) {
      console.error(err);
    } else {
      const jobs = JSON.parse(data);
      // Reschedule jobs accordingly
      scheduleJobs(jobs);
    }
  });
}

// Schedule jobs function
function scheduleJobs(jobs) {
  // Clear existing cron jobs
  cron.clear();

  // Schedule new jobs
  jobs.forEach((job) => {
    const cronJob = new cron.CronJob(job.time, () => {
      // Execute job
      executeJob(job);
    });
    cronJob.start();
  });
}

// Execute job function
function executeJob(job) {
  // Execute the job
  console.log(`Executing job: ${job.name}`);
}

Verification

To verify that the fix worked, you can:

  • Write a new job to the jobs.json file after the gateway has started.
  • Check the gateway logs to ensure that the new job is loaded and executed correctly.
  • Test the periodic re-read interval by modifying the jobs.json file and verifying that the changes are picked up within the specified interval.

Extra Tips

  • Ensure that the file watching and periodic re-read mechanisms are properly handled in environments where fs.watch is unreliable.
  • Consider implementing error handling and logging mechanisms to provide feedback to users in case of issues.
  • Review the related bug (issue #52766) and ensure that the fix does not introduce any regressions.

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…
#model save/load#optimization#mixed precision#training loop#device allocation

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 [Feature]: Cron scheduler should reload jobs.json after startup (fs.watch or periodic re-read) [1 pull requests, 4 comments, 2 participants]