Operate durable jobs with retry and idempotency gates

Verifiedon 2026-07-302026.7.1-2

Durable does not mean unattended

OpenClaw cron jobs persist job definitions, runtime state, and run history in shared SQLite state; each execution creates a background task record. That makes inspection possible, but it does not make a job safe to retry blindly.

The CLI documentation explicitly treats a lost Gateway connection as ambiguous: the Gateway may have accepted and may still finish the turn. Check Gateway status and the session transcript before retrying or rerunning, so the same work is not executed twice. Reuse a run ID only when the workflow’s deduplication design supports it.

Lab: create a retry policy

Write a policy table for the release-intelligence pipeline:

An idempotency key should represent the effect you mean to produce, for example release-digest:<source-revision>:<week>, not a random task attempt. Store the key beside the source fingerprint and terminal state.

Observable job definition

For every durable job record: schedule, timezone, selected agent/role, wall-clock budget, model/fallback policy, input key, output location, delivery target, retry class, alert owner, and disable command. A job that cannot be disabled and inspected is not ready for production.

Tabletop check

Simulate a task whose worker loses connectivity after it writes a draft but before it reports success. Your evidence pack must answer: Which input key was active? Does a draft already exist? Is the process still running? What side effect is forbidden until a human reviews it? If you cannot answer all four, retrying is unsafe.