Struct Schedule 

pub struct Schedule {
    pub id: String,
    pub cron: String,
    pub job_id: String,
    pub plan: FanoutPlan,
    pub mode: ExecMode,
    pub cooldown: Option<String>,
    pub auto_disable_when_done: bool,
    pub starting_deadline: Option<String>,
    pub runs_on: RunsOn,
    pub enabled: bool,
}

Periodic schedule (spec §2.4.3). v0.18.0 carries the fanout plan (target + optional rollout + optional jitter) inline; the referenced job (job_id → [BUCKET_JOBS]) supplies only the script body. Two schedules of the same job can target different groups on different cadences without copying the manifest.

Fields

id: String

cron: String

6-field cron expression (sec min hour day month day-of-week), matching tokio-cron-scheduler syntax.

job_id: String

Key into crate::kv::BUCKET_JOBS. Must equal a registered Manifest’s id.

plan: FanoutPlan

Who + how-to-phase + when-to-stagger. The Manifest doesn’t carry these any more — same job + different fanout = different schedule.

mode: ExecMode

Per-pc/per-target dedup semantics (v0.19). Default EveryTick keeps the historical “fire every cron tick at the whole target” behavior.

cooldown: Option<String>

Humantime cooldown for OncePerPc / OncePerTarget. Once a pc/target has succeeded, the scheduler waits this long before considering it eligible again. Omit for “succeed once, then permanently skip” — i.e. cooldown = infinity.

auto_disable_when_done: bool

When true AND the schedule’s lifecycle is permanently terminated (cooldown = None + dedup says nothing more to do), the scheduler flips enabled = false and emits an audit event. No-op when cooldown is set (re-arming schedules never finish).

starting_deadline: Option<String>

v0.22: optional humantime window after a cron tick during which the Command is still considered “live”. The scheduler computes tick_at + starting_deadline and stamps it onto each Command as deadline_at; agents skip Commands they receive after that absolute time. None (default) = no deadline, meaning a Command queued in the broker / stream during agent downtime runs whenever the agent reconnects — good for kitting / inventory / cleanup. Set this for time-of-day notifications, lunch reminders, etc., where “fire 3 hours late” would be wrong.

runs_on: RunsOn

v0.23: where does the cron tick happen? Backend (default, historical) = backend’s scheduler fires Commands via NATS; agents passively receive. Agent = each targeted agent runs its own internal cron and fires locally, so the schedule keeps ticking even when the broker is unreachable (laptop on the train, broker maintenance window, full WAN outage). The two locations are mutually exclusive — when Agent, the backend scheduler stays out and just keeps the definition in KV for agents to read.

enabled: bool

Trait Implementations

impl Clone for Schedule

fn clone(&self) -> Schedule

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for Schedule

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for Schedule

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl Serialize for Schedule

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.