Cron Retry

**Judgement** A focused, well-scoped skill that adds robust auto-retry behavior for cron jobs that fail due to transient network issues. It integrates cleanly with the standard heartbeat + cron tooling model and should materially improve reliability of message- and API-driven jobs with minimal configuration. **What it does well** - Hooks into the heartbeat loop to scan `cron list` results and automatically re-run jobs with `lastStatus: "error"` when `lastError` matches known network/connection patterns (e.g., `ECONNREFUSED`, `ETIMEDOUT`, `Network request.*failed`, `sendMessage.*failed`, `fetch failed`, `socket hang up`). - Clearly separates retryable transient errors (network, DNS, timeouts) from non-retryable ones (logic/config/auth issues, disabled jobs). - Provides simple manual recovery commands (`cron list` + `cron run --id`) for targeted debugging. - Mentions safeguards against retry loops (checks `lastRunAtMs`) and respects `enabled` state. **Key risks / limitations** - **False negatives:** Only errors matching the documented patterns get retried. Any non-standard or differently phrased network errors will be missed and require pattern updates. - **False positives / side effects:** Some errors might be misclassified as "network-like"; rerunning the job could cause duplicate side effects for non-idempotent workflows (e.g., sending the same notification or performing a write twice). - **Retry strategy is basic:** No configurable backoff, retry limits per job, or escalation; it simply retries on each heartbeat when conditions are met. - **Assumes error-field consistency:** Relies on `job.state.lastError` being informative and consistent across tools/integrations. **Recommended scenarios** Use this skill when: - Your cron jobs are primarily **idempotent** or safely repeatable (notifications, status checks, read-only syncs, report generation). - You frequently see cron jobs fail with **transient network errors** (timeouts, DNS issues, connection resets) and want them retried automatically. - You already use or are willing to adopt a **heartbeat-based health check** (via `HEARTBEAT.md`) and the standard `cron list`/`cron run` tools. Be cautious or add extra guards when: - Cron jobs perform **non-idempotent operations** (creating orders, charging cards, irreversible updates) where a second execution could be harmful. - Error messages are highly variable or localized, making pattern matching less reliable. Overall, this is a strong utility skill for improving reliability of network-dependent cron jobs in typical OpenClaw/heartbeat setups, with low operational overhead but some need for judgement around which jobs are safe to auto-retry.