echd — Echo on Encore · E3.3 · dive
A Fresh Mint Each Occurrence
A cron tick is anonymous; a recurrence on this bus mints a brand-new branded job every time it comes due — its own id, attempts, and lease — so each occurrence is a first-class unit of work.
echd speaks in the present tense over a build ladder. Every module, verb, key, and port named on this page is real; the composition into one standing platform is the vision the ladder builds.
The dive
docs/echo_mq/specs/emq1/emq.1/emq.1.md:13-44Cron fires an action. It runs the same anonymous function on a timer, and when the tick is done there is nothing left behind — no id, no record, no thing to retry. EchoMQ.Repeat refuses that shape. It registers a recurrence, and when an occurrence comes due it mints a fresh branded JOB — a new id, a new attempts counter, a new lease. The occurrence is not a function fired; it is a job created, with everything a job has: a name to track it, a retry policy to recover it, a place in metrics to see it.
That single decision — mint, do not re-fire — is what makes recurring work first-class. Two occurrences of the same schedule share nothing but the rule that spawned them, so a Tuesday run that fails does not poison Wednesday's, and an occurrence that overruns does not collide with the next. The schedule itself is a visibility fence over a scored set: entries hidden until their run-at, then promoted to ready by a supervised pump, EchoMQ.Pump, on the server's clock — so "due" is a fact the bus decides, never a caller's wall clock.
A recurrence, minted fresh
docs/echo_mq/specs/emq1/emq.1/emq.1.md:13-44EchoMQ.Repeat records a schedule — nightly, hourly, a cron expression — as a registration, not a queue and not a running timer. It is a rule for when to mint, held on the bus, and it survives restarts because it lives with the data, not inside a process.Repeat mints a brand-new JOB — its own id, its own attempts counter, its own lease. Two occurrences share nothing but the schedule that spawned them, so one can retry, fail, or be inspected without touching the next. A cron tick is anonymous; a minted job has a name.EchoMQ.Pump, sweeps the set on the server's clock and promotes due work to ready — so "due" is decided by the bus, never by a caller's wall clock.Hover or focus a part to read it; click to pin. Without scripting, all three read in sequence.
Why a fresh mint, not a re-fire
docs/echo_mq/specs/emq1/emq.1/emq.1.md:13-44The difference between firing and minting is the difference between a tick and a record. A cron tick has no identity, so it cannot be tracked, retried, or reasoned about after the fact: if it fails, the failure is a log line at best. A minted occurrence is a job, so everything the bus does for jobs, it does for it — the attempts counter drives retry with backoff, the lease protects it under a claim, and it appears in metrics and, on death, in the morgue. Recurring work stops being a special case and becomes ordinary work that happens to arrive on a schedule.
The subtlety the scheduler has to get right is once, exactly, per occurrence — the Pump must promote a given occurrence a single time, not zero times and not twice. It does this by making the schedule set a scored, server-clock-gated fence: an entry is due when the server's TIME passes its score, and the promote step moves it atomically, so a fresh mint appears for each occurrence and no more. The recurrence is the rule; the mint is the instance; and because the instance is a full branded job, the whole lifecycle of the platform — claim, retry, metrics, archive — is available to work that used to be a disappearing tick.
The rule
one line to carryThe occurrence rule — a recurrence mints a fresh branded job each time it comes due, so every occurrence has its own id, attempts, and lease. Cron fires an anonymous tick with nothing to track; EchoMQ.Repeat creates a first-class job that the Pump promotes on the server's clock — a failed occurrence retries itself and never poisons the next.
Doors
the scheduler, in depthEchoMQ — the protocol, in depth
enqueue_at, enqueue_in, the @schedule script, EchoMQ.Repeat, and the Pump — the scheduling and repeat families in full.
the schedule set, exact — how due work is scored and promoted.
/redis-patternsRedis Patterns, Applied
Delayed and scheduled jobs as a pattern: the scored set, the promote sweep, and idempotent occurrence.
a scored set, swept — the delay pattern the scheduler is built on.
References
sources · relatedSources
- Valkey — Data typesthe sorted set the schedule set is: entries scored by run-at, ranged by time
Related
- E3.3 — Jobs Supersede Cron and Queuesthe module this dive opens
- fair-lanes-and-the-metronomethe next move: how a minted job is claimed and scheduled fairly
- the-braced-keyspacethe server clock the Pump promotes on