Module run 

The run record and the scheduler: a run is a durable transition log over a workflow’s DAG — per-step {status, attempt, started, finished, output, error}, vars, the start payload, budgets and the terminal outcome. The scheduler is pure: given a workflow and a run it names the steps that are ready (all depends_on terminal, when true), applies step outcomes (on_error routing, goto recovery edges), and decides the run’s terminal state (finish reached, failed, cancelled, or stalled — no ready step and no finish).

Structs

RunState

The durable run record: the whole state of one run, and the only thing that has to survive a restart for the scheduler to carry on where it stopped.

Start

How the run started: which start node fired, what payload it carried, and when. Visible to templates as run.start.

StepState

One step’s durable state.

Enums

Next

What the scheduler wants done next.

RunStatus

StepStatus

Functions

deadline_passed

Whether the run’s deadline passed.

env_view

idempotency_key

The env view (curated, secret-free) the templates see. The idempotency key for one step of one run: stable across retries and replays BY ARITHMETIC — it is derived from identity every attempt of the same logical operation already shares — and distinct across runs because run ids are. Hashed so the remote learns nothing: a raw run.step would leak ULID timestamps and internal step names to every API that logs its keys, which is the good instinct behind wanting keys random. Deterministic derivation gets the opacity without the persistence, and without the crash-window a mint-then-store scheme has to defend forever.

render_spec

Render a step’s spec against the run data (every field, recursively).

route_failure

Apply a failed step’s on_error policy: returns the steps to schedule next (a goto target) or Err(reason) when the run must fail.

schedule

Compute the ready steps. when guards are evaluated over data; a false guard skips the step (durably) — hence &mut RunState.