Background

RemoteClaw is a fork of OpenClaw that keeps the channel-adapter, gateway, and cron infrastructure but replaces OpenClaw's in-process execution engine with CLI-based agent runtimes (and removes the model-provider, sandbox, and memory subsystems). Cron is part of the kept infrastructure and lives in src/cron/.

This item was identified while syncing upstream OpenClaw (the v2026.4.15 → v2026.4.20 range) and deferred for a focused follow-up because the fix was entangled in a larger timer refactor that does not apply cleanly to the fork.

Problem

OpenClaw shipped a fix for a cron scheduling bug: a job whose next run-time could not be resolved would fail to refire (it was not rescheduled and silently stopped running). This correctness fix was not carried into RemoteClaw during the last upstream sync.

Where to look (upstream OpenClaw, v2026.4.15..v2026.4.20)

The fix is buried in a larger timer/scheduling refactor. Candidate trail to verify:

• e1fe71872c3 — test: share unresolved cron next-run fixtures (the test fixtures for this behavior)
• 1d4e4314ddd — fix: preserve deferred cron heartbeat target (#69021) (related cron-scheduling fix)

Start from the test fixtures to identify the exact runtime change, then trace it to the scheduling code.

Task

1. Identify the specific "unresolved next-run → refire" fix in the upstream range above.
2. Port it into src/cron/, adapting to the fork's consolidated structure. Do not import any removed/gutted subsystem; if the upstream fix references one, port only the cron-scheduling portion.
3. Port (or write) a regression test covering the unresolved-next-run case.

Acceptance criteria

• A cron job whose next run-time is initially unresolved is correctly rescheduled and fires on a subsequent tick.
• A regression test asserts the refire behavior and passes in isolation.