The Cron, Re-minted

An Encore cron entry is a timer bound to a function: when the schedule fires, the function runs, and the run leaves nothing behind. Re-minting it changes what an occurrence is. You register EchoMQ.Repeat with the same schedule, and now each occurrence is not a function call but a fresh branded JOB — 02:00 today is one id, 02:00 tomorrow another. The schedule becomes a rule for minting, and the mint is a first-class job with its own attempts, its own lease, and its own place in metrics.

Run it and the abstract claim becomes two ids you can read. Register the recurrence, let two occurrences come due, and inspect the ready set: two distinct jobs, not one action fired twice. Fail one on purpose and it retries on its own attempts clock while the other proceeds untouched — proof that the occurrences are independent. And because a supervised pump, EchoMQ.Pump, promotes each due occurrence exactly once on the server's clock, the re-minted cron fires on time and once, whatever any caller's wall clock believes.

The whole argument for re-minting fits in one observation you can make at a terminal: after two occurrences come due, the ready set holds two different branded ids, and a cron would have left none. That difference is not cosmetic. A named job can be tracked in metrics, retried on its own attempts clock, inspected in the morgue when it dies, and reasoned about after the fact. A cron tick can be none of these, because it has no identity to hang any of them on.

The subtlety worth watching in the run is exactly once per occurrence. The Pump must promote a given occurrence a single time — not zero times if the sweep is late, not twice if it overlaps — and it does so by treating the schedule set as a scored, server-clock-gated fence and moving each due entry atomically. Advance the clock, watch one fresh mint appear per occurrence and no more, and you have seen the property that lets recurring work join the ordinary lifecycle of the bus: minted, promoted, claimed, retried, archived — a schedule that produces jobs instead of firing ticks.

The re-minting rule — a cron becomes a Repeat registration whose every occurrence is a fresh branded job, promoted once on the server clock. Run it and read two distinct ids where a cron would have left one anonymous tick — each retryable on its own, each promoted exactly once, each a job the platform can see.