pub struct FanoutPlan {
pub target: Target,
pub rollout: Option<Rollout>,
pub jitter: Option<String>,
pub deadline_at: Option<DateTime<Utc>>,
}Expand description
“Who + how + when-to-stagger” — the fanout-plan side of an exec.
Used both as the POST /api/exec/{job_id} body and as the embedded
target / rollout / jitter slot on Schedule. Centralising
here keeps the validation + serialisation logic in one place.
Fields§
§target: Target§rollout: Option<Rollout>Optional wave rollout — when present, the backend publishes
each wave’s group subject on its own delay schedule instead
of fanning out the target block in one go. target then
only labels the deploy for the audit log.
jitter: Option<String>Optional humantime jitter; agent uses it to randomise execution start. Lives here (not on the script) so different schedules / ad-hoc fires of the same job can pick different stagger windows.
deadline_at: Option<DateTime<Utc>>Absolute time the scheduler stamps on each emitted Command
when this exec was driven by a Schedule with
starting_deadline. Agents receiving a Command after this
instant publish a synthetic skipped-result instead of
running the script. None (default) = no deadline / catch
up whenever delivered. Operators don’t usually set this
directly — the scheduler computes it from tick_at + starting_deadline.
Trait Implementations§
Source§impl Clone for FanoutPlan
impl Clone for FanoutPlan
Source§fn clone(&self) -> FanoutPlan
fn clone(&self) -> FanoutPlan
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more