openclaw - 💡(How to fix) Fix tasks audit reports inconsistent_timestamps for successful tasks when startedAt < createdAt by a few ms [1 participants]

Summary

openclaw tasks audit reports repeated inconsistent_timestamps warnings for successful task runs because startedAt can be persisted a few milliseconds earlier than createdAt.

This does not appear to break task execution, but it adds noise to tasks audit and openclaw status, making it harder to spot real task issues.

Version

• OpenClaw 2026.4.5
• macOS app 2026.4.5
• Host: macOS 26.4

What I observed

openclaw status showed:

• Tasks: 0 active · 0 queued · 0 running · 1 issue · audit 54 warn · 64 tracked

After investigating with openclaw tasks audit, all warnings were the same code:

• inconsistent_timestamps
• detail: startedAt is earlier than createdAt

Example finding:

• taskId: 42a25c95-5ecb-4558-9ff6-6af696298c01
• status: succeeded
• createdAt: 1775491200009
• startedAt: 1775491200007
• endedAt: 1775491220290

Another example:

• taskId: 3946b48a-a25a-473f-93f1-7672c43cc3cb
• status: succeeded
• createdAt: 1775129822638
• startedAt: 1775129822627
• endedAt: 1775129826390

The delta is tiny, usually just a few milliseconds, and tasks still complete successfully.

Why this seems like a bug

The recorded lifecycle becomes logically inconsistent:

1. task is created
2. task starts
3. task ends

But the stored timestamps can show step 2 happening before step 1.

That makes tasks audit warn on many healthy tasks and inflates the warning count in openclaw status.

Expected behavior

Either:

• createdAt <= startedAt <= endedAt

or, if the current write order is intentional, the audit should tolerate very small deltas and avoid flagging these as warnings.

Possible fixes

Any of these would help:

1. Ensure createdAt is stamped before startedAt
2. Normalize task timestamps before persistence
3. Relax the audit rule for very small deltas (for example a few ms)

Impact

• No obvious runtime breakage
• But it creates audit noise and reduces confidence in task health reporting

Extra note

I also had one genuinely failed historical task in the ledger. After removing that old failed row manually from the local task sqlite, openclaw status changed from:

• 1 issue · audit 54 warn · 64 tracked

to:

• no issues · audit 53 warn · 63 tracked

So the remaining warnings were still entirely explained by this timestamp pattern.