Skip to main content

Module engine

Module engine 

Source
Expand description

The workflow engine: the workflow model and its validation (model), templates (template), the data steps (data) and the durable run record with its pure scheduler (run).

The split that matters: everything here is pure. Step execution — turn workers, MCP calls, internal tools, timers — belongs to crate::runtime. The engine only says what is ready to run and records what happened, which is what lets a run be scheduled deterministically from its checkpoint after a restart.

Re-exports§

pub use model::Workflow;
pub use model::parse_workflow;
pub use model::workflow_schema;
pub use run::Next;
pub use run::RunState;
pub use run::RunStatus;
pub use run::StepStatus;

Modules§

data
The data steps: array and text operations that need no model — map, filter, reduce, sort, dedupe, chunk, parse — as pure functions over JSON values. Element expressions are CEL (item, index, acc, plus the run data) or {{template}} strings; by keys are dotted paths. Being pure and model-free, these steps cost nothing to replay, so the runtime may re-run them after a crash instead of checkpointing each one.
model
The workflow model: a named DAG of steps beginning at start nodes, parsed from a JSON or YAML document and validated for acyclicity, reachability, finish reachability, dependency existence, schema well-formedness, CEL compilation and the caps.
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).
template
Workflow templates: {{path}} interpolation with dotted / JSON-pointer paths and {{path | default}} over the run data (inputs, run, steps.<id>.output, vars, memory.<key>, item, index, batch, env), plus CEL: expressions over the same names (feature cel; a non-CEL build refuses them at validation). Dependency-free.