PR #74068: fix(cron): reject invalid schedule edits before mutation

• Repository: openclaw/openclaw
• Author: ai-hpc
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/74068

Description (problem / solution / changelog)

Summary

• Problem: cron edit <id> --cron <invalid> could persist an invalid cron expression when the target job was disabled, and a later failed cron enable could leave the invalid job enabled in live state.
• Why it matters: rejected cron input should never mutate in-memory or persisted scheduler state; this creates confusing CLI output and schedule-error state after an operation that returned an error.
• What changed: validate cron schedules in the gateway handler before calling cron.add / cron.update, so invalid Croner expressions are rejected before the cron service applies any patch.
• What did NOT change (scope boundary): no changes to cron execution, retry/backoff policy, persistence format, delivery behavior, or existing cleanup/repair paths.

Change Type (select all)

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

Scope (select all touched areas)

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

Linked Issue/PR

• Closes #74459
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: cron.update applies patches in-place before computing the next run. The gateway handler validated only timestamp shape before calling context.cron.update(...), so disabled jobs could bypass schedule computation and persist invalid cron expressions.
• Missing detection / guardrail: gateway validation did not validate cron expressions before service mutation.
• Contributing context (if known): disabled jobs do not compute a next run during edit, so the invalid cron expression was not rejected on that path.

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/gateway/server-methods/cron.validation.test.ts
• Scenario the test should lock in: invalid cron schedules are rejected before context.cron.add / context.cron.update, including disabled-job updates.
• Why this is the smallest reliable guardrail: the bug is at the gateway boundary before the cron service mutation call.
• Existing test that already covers this (if any): none for the disabled-job pre-mutation path.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

cron edit <id> --cron <invalid> now fails before mutating disabled jobs, matching the expected behavior for invalid cron input.

Diagram (if applicable)

Before:
cron edit disabled job --cron invalid -> patch applied -> exit 0 -> invalid schedule persisted
cron enable same job -> error returned -> live state may still show enabled invalid job

After:
cron edit disabled job --cron invalid -> gateway validation rejects -> previous schedule remains unchanged

Security Impact (required)

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

Repro + Verification

Environment

• OS: Ubuntu 24.04.4 LTS
• Runtime/container: Node 22.22.1 / pnpm dev
• Model/provider: N/A
• Integration/channel (if any): Cron gateway RPC
• Relevant config (redacted): isolated OPENCLAW_STATE_DIR source gateway on loopback

Steps

1. Create a disabled valid cron job with cron add --every 10m --session main --system-event "probe" --disabled.
2. Run cron edit <job-id> --cron "* * * 13 *".
3. Inspect cron show <job-id> --json and jobs.json.

Expected

• Invalid cron expression is rejected.
• Previous valid schedule remains in live state and persisted jobs.json.

Actual

• Before this PR: invalid cron schedule could be persisted on disabled jobs.
• After this PR: invalid cron edit returns INVALID_REQUEST, and the previous valid every schedule remains unchanged.

Evidence

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

Targeted test:

pnpm test src/gateway/server-methods/cron.validation.test.ts -- --reporter=verbose
# 10 tests passed

Build:

pnpm build
# passed

Changed gate note:

pnpm check:changed -- --base openclaw/main
# touched production typecheck passed; current main has an unrelated core test type error in src/gateway/channel-health-policy.test.ts:235

Human Verification (required)

What I personally verified (not just CI), and how:

• Verified scenarios: isolated source gateway smoke reproduced the disabled-job invalid cron edit; after the fix, cron edit <id> --cron "* * * 13 *" returns exit 1 and both cron show and jobs.json keep the original valid every schedule.
• Edge cases checked: invalid cron.add schedule rejection before service mutation; invalid cron.update schedule rejection before service mutation; disabled-job update path.
• What I did not verify: long-running cron execution timing, delivery channels, or production systemd gateway behavior.

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/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: Cron validation now happens before service mutation, so any cron expression Croner rejects will be rejected earlier than before.
  • Mitigation: this matches the intended invalid-input behavior and is covered by gateway boundary tests.

Changed files

• src/gateway/server-methods/cron.ts (modified, +33/-0)
• src/gateway/server-methods/cron.validation.test.ts (modified, +44/-0)

PR #74654: fix(cron): validate cron expression before mutating stored job on update (#74459)

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

Description (problem / solution / changelog)

Summary

Fixes #74459.

cron edit <id> --cron <invalid> on a disabled job silently persisted the invalid expression — the scheduler's next-run computation was skipped for disabled jobs, so the invalid cron string passed through applyJobPatch without error. A subsequent cron enable would then set enabled = true before Croner threw, leaving the job stuck in an enabled-but-unscheduled state.

Fix

Two-layer guard before any mutation in cron.update:

1. Schedule validation helper — validateCronScheduleExpr exported from src/cron/schedule.ts. Calls Croner with the expression; throws RangeError on invalid input.
2. Pre-mutation call in ops.ts — validates before applyJobPatch when:
   • the patch supplies a new cron expression, OR
   • the patch enables a job whose existing schedule is cron-kind (catches the double-failure path)

Both paths throw before any field is mutated, so on-disk job state is never corrupted.

Tests

• src/cron/service.issue-regressions.test.ts: 2 new regression tests at service level
  • disabled job: invalid --cron rejected before persist
  • disabled job: valid --cron accepted; subsequent cron enable with a corrupted schedule throws
• src/gateway/server-methods/cron.validation.test.ts: 1 gateway-level regression test

Tests  20 passed (20) across 2 shards

Audit

• Audit A (existing helper): validateCronExpression not present; validateCronScheduleExpr is a new focused helper in schedule.ts (consistent with the module's existing CronSchedule type)
• Audit B (shared callers): ops.ts#updateCronJob — 1 caller path. New guard is additive (throws before mutation), no contract change for valid inputs
• Audit C (broader rival): PR #74068 addresses gateway-layer validation only (2 files). This fix adds service-layer validation + a shared validateCronScheduleExpr helper (5 files, wider coverage). Complementary rather than competing — both layers benefit.

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/cron/schedule.ts (modified, +4/-0)
• src/cron/service.issue-regressions.test.ts (modified, +67/-0)
• src/cron/service/ops.ts (modified, +9/-0)
• src/gateway/server-methods/cron.validation.test.ts (modified, +31/-0)

PR #74720: fix: reject invalid cron edits on disabled jobs

• Repository: openclaw/openclaw
• Author: yfge
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/74720

Description (problem / solution / changelog)

Summary

• validate cron schedule edits before persisting them, even when the target job is disabled
• make cron.update transactional so failed enable/update attempts do not partially mutate stored jobs
• add regression coverage for both invalid disabled edits and failed enables against already-invalid disabled jobs

Testing

• pnpm vitest run src/cron/service.issue-regressions.test.ts src/gateway/server-methods/cron.validation.test.ts

Closes #74459.

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/cron/service.issue-regressions.test.ts (modified, +55/-0)
• src/cron/service/ops.ts (modified, +29/-17)

PR #13: fix(cron): reject invalid cron expressions on disabled jobs before persisting

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

Description (problem / solution / changelog)

Closes openclaw/openclaw#74459

Problem

openclaw cron edit <id> --cron "invalid expr" on a disabled job silently persisted the invalid expression. Two bugs:

1. ops.update only calls computeJobNextRunAtMs (which validates via croner) for enabled jobs. Disabled jobs skip that path entirely, so invalid cron syntax passes through to persist().
2. When the user later ran cron edit --enable, applyJobPatch set job.enabled = true before computeJobNextRunAtMs threw, leaving the in-memory state.store.jobs entry with enabled: true even though persist was never reached. This "live state" corruption persisted until the next forced reload from disk.

Root cause

src/cron/service/ops.ts:update:

applyJobPatch(job, patch, ...); // mutates job.enabled = true in-place
// ...
if (job.enabled) {
  job.state.nextRunAtMs = computeJobNextRunAtMs(job, now); // only here does croner throw
}
// For disabled jobs: skips computeJobNextRunAtMs entirely → persist runs with invalid expr

Fix

Added validateCronScheduleExpr(schedule) to src/cron/validate-timestamp.ts. It dry-runs computeNextRunAtMs in a try/catch to detect croner parse errors for any cron-kind schedule.

Three call sites:

• gateway/server-methods/cron.ts — cron.add and cron.update handlers: validate before reaching context.cron.* (returns structured error to caller)
• src/cron/service/ops.ts — update: validate before applyJobPatch so the job object is never mutated when the expression is invalid (defense in depth)

Tests

New file src/cron/service.cron-invalid-expr.test.ts (3 tests):

• Rejects invalid cron expression on a disabled job; original schedule unchanged
• Rejects invalid expression when trying to enable with the bad schedule
• Accepts a valid cron expression change on a disabled job

Generated by Claude Code

Changed files

• src/cron/service.cron-invalid-expr.test.ts (added, +133/-0)
• src/cron/service/ops.ts (modified, +9/-0)
• src/cron/validate-timestamp.ts (modified, +23/-0)
• src/gateway/server-methods/cron.ts (modified, +18/-1)

PR #74812: fix(cron): validate cron expression before persisting to job state

• Repository: openclaw/openclaw
• Author: Linux2010
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/74812

Description (problem / solution / changelog)

Summary

Fixes #74459: Prevents invalid cron expressions from being persisted in disabled jobs that would fail silently when enabled later.

Problem

When a cron job is disabled, users can save invalid cron expressions (e.g., * * * 13 * - month 13 doesn not exist). The expression is stored without validation. When the job is enabled later, it fails at runtime with no clear error message.

Solution

Add upfront cron expression validation using the croner library (same library used for computing next run times) in gateway handlers:

1. cron.add: Validate cron expressions before creating the job
2. cron.update: Validate cron expressions before applying the patch

This ensures invalid expressions are rejected with clear error messages BEFORE they are saved to job state, not at runtime.

Implementation

• Create validateCronExpression() in src/cron/validate-cron-expression.ts
• Validate in both cron.add and cron.update gateway handlers
• Add comprehensive test coverage for valid/invalid expressions

Testing

Added tests in:

• src/cron/validate-cron-expression.test.ts - unit tests for validation function
• src/gateway/server-methods/cron.validation.test.ts - integration tests for gateway handlers

Test cases include:

• Valid expressions: * * * * *, 0 0 * * *, with timezone
• Invalid expressions: month 13, day of week 8, hour 25, empty/undefined
• Edge cases: whitespace, predefined aliases (@daily, @hourly)

Checklist

• Issue linked in title and body
• Semantic commit message format
• Test coverage added
• No CHANGELOG update (maintainers handle this)

Changed files

• src/cron/validate-cron-expression.test.ts (added, +98/-0)
• src/cron/validate-cron-expression.ts (added, +61/-0)
• src/gateway/server-methods/cron.ts (modified, +32/-0)
• src/gateway/server-methods/cron.validation.test.ts (modified, +92/-0)