openclaw - 💡(How to fix) Fix [cron] announce-on-failure replay should dedup by intent [1 comments, 2 participants]

Summary

When a cron.add (or cron.update) fails validation, the rejection is logged into the gateway's announce-on-failure stream and replayed at the originally-scheduled fire time. If the operator/agent retries with a corrected payload under a new cron job ID, the stale failure is still announced at fire time, surfacing a misleading rejection while the actual reminder is running on a different working ID.

Repro

1. cron.add with sessionTarget="main" on a non-default agent. Gateway rejects with sessionTarget "main" is only valid for the default agent.
2. cron.add again with the corrected sessionTarget="isolated" + payload.kind="agentTurn". Job stored, scheduled.
3. At the scheduled fire time, the stale rejection from step 1 is announced to the configured channel.

Proposed fix

Dedup announce-on-failure deliveries by intent. The intent key could be (agentId + scheduleName + scheduleTime) or a hash of those fields. When a successful schedule lands with the same intent key as a previous failure, mark the failure entry as superseded so the announce skips it.

Why this matters

The failure-replay surfaces stale errors to operator chats long after the operator has corrected the issue, eroding trust in the cron system. Combined with the documentation gap (the canonical Block 0 cron tool description doesn't mention the sessionTarget constraint, so non-default agents reasonably default to "main" and trip this exact path), it creates a fail-then-discover loop that's measurably bad for operator UX.

Workarounds we shipped locally (in case OpenClaw wants to reference them)

We documented the sessionTarget constraint inline in the canonical Block 0 cron tool description as a line-scoped prompt-policy transform (so non-default agents see it before failing first), and added a platform-side validator that rejects session_target="main" at the HTTP boundary so the gateway never logs the failure in the first place. These close the agent-side and platform-side legs respectively, but the gateway-side replay-dedup is the right canonical fix for the failure-stream replay class.