Expand description
Execution plans – what a run would do, without doing it.
Ironflow workflows are Rust-native handlers, not declarative graphs: the only way to know which steps a run would create is to execute the handler with every step method short-circuited. That is what plan mode is.
A recorder is attached to a
WorkflowContext by
Engine::plan_handler. Every step
entry point checks it first, records a PlannedStep, and returns a
synthetic StepOutput without touching the store, the provider, the
event bus or the network.
§The success-shaped output assumption
Synthetic outputs are shaped like a successful step (exit_code: 0,
status: 200), so a native if build.is_success() branch in the handler
follows the happy path. A plan therefore shows the nominal branch, not
every branch the run might take. Conditions declared with
WorkflowContext::when are
evaluated against the run input and reported; those declared with
WorkflowContext::when_dynamic
are reported as ConditionResult::Unevaluable.
§Why the global dry-run flag is not used
ironflow_core::dry_run exposes a process-wide switch. Plan mode does not
flip it: nothing is executed while planning, so the flag would buy nothing,
and flipping a process-wide flag would corrupt real runs executing
concurrently in the same process.
Structs§
- Execution
Plan - The full plan for one workflow and one input payload.
- Plan
Options - Knobs for
Engine::plan_handler. - Planned
Step - One step the planner expects the run to create.
Enums§
- Condition
Result - Outcome of a branch condition as seen by the planner.
Constants§
- DEFAULT_
ESTIMATE_ SAMPLE_ RUNS - How many past runs are sampled to estimate step durations.
- DEFAULT_
PLAN_ MAX_ DEPTH - How deep sub-workflows are expanded when the caller does not say.
- MAX_
PLANNED_ STEPS - Hard cap on the number of steps a single plan may record.
Functions§
- estimate_
durations - Average completed-step durations for a workflow, keyed by step name.