Cron jobs without id field cause runtime state to collapse into first job (find-collision)

Summary

When ~/.openclaw/cron/jobs.json contains jobs missing the id field, the scheduler's Array#find() matches the first entry every time, causing every job's runtime state (errors, lastRunAtMs, nextRunAtMs, consecutiveErrors) to be written into the first job's slot. This makes diagnostics deeply misleading — one job appears to be the source of all failures when in fact it may be uninvolved.

Version

[email protected] (npm-global install, Linux x86_64, Ubuntu 24.04.4)

Repro

1. Create ~/.openclaw/cron/jobs.json with multiple jobs[] entries that have name set but no id field. (This is the natural state when jobs.json is hand-authored or migrated from older config that didn't require id.)
2. Restart openclaw-gateway.
3. Let any cron job error.

Symptom

• The first job in the array accumulates consecutiveErrors, lastError, lastRunAtMs, nextRunAtMs from all other jobs.
• Journal shows [cron:undefined] log lines (e.g. [cron:undefined] skipping stale delivery scheduled at <timestamp>).
• A disabled: true job can appear to be the failing one even when it never fires, because it occupies the first slot.

Root cause

In dist/server.impl-DYBxSjUs.js, applyOutcomeToStoredJob matches by id:

const job = jobs.find((entry) => entry.id === result.jobId);

When all jobs have id === undefined, this returns the first entry unconditionally.

The constructor path (createJob in dist/jobs-CXWpCyUn.js line 526–555) already generates crypto.randomUUID(), but plain config-load via loadCronStore (dist/store-C0bwjphP.js) does not backfill. normalizeCronJobIdentityFields only migrates legacyJobId → id; with neither field present, raw.id stays undefined.

Other affected paths (verified by grep): runDueJob (server.impl line 4798), nextWakeAtMs job iteration (jobs.js line 513).

Proposed fix

Two changes:

1. Backfill UUIDs at load time in loadCronStore / ensureLoaded

import { randomUUID } from "node:crypto";

for (const job of jobs) {
    const raw = job;
    const { legacyJobIdIssue } = normalizeCronJobIdentityFields(raw);
    if (legacyJobIdIssue) { /* existing warn */ }
    if (typeof job.enabled !== "boolean") job.enabled = true;
    if (typeof job.id !== "string" || !job.id.trim()) {
        job.id = randomUUID();
        state.deps.log.warn(
          { storePath, jobName: job.name, newId: job.id },
          "cron: backfilled missing id for job; writing canonical shape"
        );
        state.requiresPersist = true;
    }
}
if (state.requiresPersist && !opts?.skipPersist) await persist(state);

2. Defensive guard against undefined jobId

In applyOutcomeToStoredJob (server.impl line 4697), runDueJob (line 4798), and the collectRunnableJobs mapping:

if (result.jobId === undefined) {
    state.deps.log.error({ result }, "cron: refusing to apply outcome with undefined jobId");
    return;
}
const job = jobs.find((entry) => entry.id === result.jobId);

User-visible workaround (no patch required)

Add explicit UUIDs to each job in ~/.openclaw/cron/jobs.json:

python3 -c 'import uuid; [print(uuid.uuid4()) for _ in range(N)]'

Paste one per job under each entry's id field. Then reset the polluted state of the first job so accumulated errors don't influence the next run:

jq '(.jobs[] | select(.name == "<first_job_name>")).state = {}' \
  ~/.openclaw/cron/jobs.json > /tmp/jobs.json.new && \
  mv /tmp/jobs.json.new ~/.openclaw/cron/jobs.json

Why this matters

The find-collision silently misattributes state across jobs. Operators investigating "why is job X failing 46 times" can spend hours chasing the wrong job — in our case, auto-memory-dream (disabled) appeared to be the failing one when in fact health-snapshot was OOM-ing on Ollama and its errors were being recorded in auto-memory-dream's slot. The [cron:undefined] log line is the only visible tell.

Affected files (v2026.4.20)

• dist/jobs-CXWpCyUn.js — createJob already has UUID gen; normalizeCronJobIdentityFields is the migration entrypoint that should fall through to UUID gen for missing-id case
• dist/store-C0bwjphP.js — loadCronStore (where the backfill should happen)
• dist/server.impl-DYBxSjUs.js — applyOutcomeToStoredJob (line 4697), runDueJob (line 4798), collectRunnableJobs