Module schedule 

Schedules: workflows started by a cron expression or a fixed interval.

A schedule is a row in orbit_schedules (see crate::store): its specification (workflow, input, timing and policies) as JSON, and its progress (the next occurrence, the last execution, counters). Any server that can write fires due occurrences from its tick:

1. Claim. UPDATE ... WHERE next_fire_ms = <the occurrence> AND <no live claim> sets a claim with a lease. Of several servers that find the same occurrence due (shared mode), exactly one gets it.
2. Fire. The overlap and catch-up policies decide whether to start an execution. Its id is <schedule-id>:<occurrence, RFC 3339 UTC>, so a start repeated after a crash is the existing idempotent start.
3. Advance. A second compare-and-set records the outcome, moves next_fire_ms to the following occurrence and drops the claim.

A server that dies between 1 and 3 leaves a claim that expires after CLAIM_MS; then any server takes the occurrence again, and the deterministic id makes the second start a no-op.

Times are milliseconds since the Unix epoch. Cron expressions are evaluated in the schedule’s IANA time zone (UTC by default) with the time-zone database bundled into the binary.

Structs

CreateSchedule

Body of POST /v1/schedules.

Cron

A parsed five-field cron expression (minute hour day-of-month month day-of-week), with the usual extensions: lists, ranges, steps, month and weekday names, 7 for Sunday, and the @hourly … @yearly macros.

Plan

When a schedule fires, compiled from its specification.

ScheduleSpec

A schedule’s specification: the JSON of POST /v1/schedules (without schedule_id and paused), stored in orbit_schedules.spec.

Triggered

The result of firing a schedule now (POST /v1/schedules/{id}/trigger).

Enums

Catchup

What happens to occurrences that passed while no server could fire them.

Overlap

What happens when an occurrence is due while the previous execution this schedule started is still running.

Constants

CLAIM_MS

How long a server’s claim on an occurrence lasts.

MISSED_AFTER_MS

An occurrence handled more than this late counts as missed (catch-up policy).

POLL_MS

Due schedules are looked up at most this often (and when one changes on this server).

RETRY_MS

After a failed start, the occurrence is retried this much later.

Functions

fire_execution_id

The execution id of an occurrence: <schedule-id>:<occurrence>.

format_time

Milliseconds since the Unix epoch as RFC 3339 in UTC.

parse_duration

15m, 1h30m, 500ms, 2d: a sum of whole numbers with units.

parse_time

Parse an RFC 3339 timestamp to milliseconds since the Unix epoch.

valid_schedule_id

Schedule ids: letters, digits, -, _ and ., at most 100 characters.

view

The API view of a schedule: its specification, its state and its next fire times.