Summary

openclaw tasks audit reports large numbers of inconsistent_timestamps warnings where startedAt is earlier than createdAt, even though the tasks appear to have completed normally. On this host the warning count was 954, with 953 warnings of this form and no corresponding operational failure.

Version / environment

• OpenClaw: 2026.4.24 (cbcfdf6)
• Host OS: Ubuntu 22.04.3 LTS
• Runtime observed from local installed distribution under ~/.openclaw/plugin-runtime-deps/openclaw-2026.4.24-...

What I observed

openclaw tasks audit --json reported:

• warnings: 954
• byCode.inconsistent_timestamps: 954
• warning detail: startedAt is earlier than createdAt

Representative rows from ~/.openclaw/tasks/runs.sqlite:

• task 7e2001c0-cada-4682-bd92-e3e1e3745f34: created_at=1777078430262, started_at=1777078430238 (delta 24 ms)
• task 347f9eb9-7be2-4e95-a4a6-2b8b00fc3fda: created_at=1776998259428, started_at=1776998259410 (delta 18 ms)
• task 18a6b4fa-d92a-4763-9e42-bb39d06a6f31: created_at=1776896555577, started_at=1776896555572 (delta 5 ms)

These tasks were otherwise terminal/succeeded and not obviously broken.

Relevant code paths

The local installed bundle appears to do two things that make this warning easy to trigger:

1. The audit logic flags any strict inversion with no tolerance:

if (task.startedAt && task.startedAt < task.createdAt) {
  // warn: inconsistent_timestamps
  // detail: "startedAt is earlier than createdAt"
}

1. Task timestamps appear to come from separate Date.now() calls / fallback paths. One observed snippet from the local installed bundle:

const createdAt = params.createdAt ?? Date.now();

This makes it plausible for startedAt and createdAt to drift by a few milliseconds if they are sampled independently during task creation / start transitions.

Why this seems like a bug

This produces a large volume of audit noise for tasks that are not operationally unhealthy. The audit output makes the task store look broken even when the issue appears to be timestamp sampling/ordering jitter.

Suggested fixes

Any of these would likely solve it:

1. Use a shared nowMs when creating/updating a task row so createdAt and startedAt are internally ordered.
2. Normalize ordering when both values exist (for example clamp createdAt <= startedAt when appropriate).
3. Add a small tolerance in audit (for example ignore startedAt < createdAt when the delta is under a small threshold like 10-50 ms).

My preference would be (1), possibly with (3) as belt-and-braces.

Impact

Low severity, but high annoyance/noise. On this host it drowned the task audit in false-positive warnings and made it harder to spot the one genuinely actionable task issue.