pub struct SchedulerState {Show 26 fields
pub run_id: String,
pub superstep: u64,
pub phase: Phase,
pub node_gen: Vec<u32>,
pub node_state: Vec<NodeState>,
pub in_res: Vec<BTreeMap<usize, EdgeRes>>,
pub edge_fired: Vec<u32>,
pub attempt: Vec<u32>,
pub attempt_base: Vec<u32>,
pub context: Value,
pub spent: Spent,
pub elapsed_ms: u64,
pub clock_ms: u64,
pub wall_open: Option<u64>,
pub paused_at: Option<u64>,
pub pending_asks: BTreeMap<String, PendingAsk>,
pub abstract_flows: BTreeMap<String, AbstractFlow>,
pub send_tasks: BTreeMap<String, SendTask>,
pub spawn_counter: BTreeMap<String, u32>,
pub announced_asks: BTreeSet<String>,
pub inbox: Vec<Value>,
pub inputs_seen: u64,
pub cancel: Option<(String, String)>,
pub exhausted: Option<BudgetAxis>,
pub failed: Option<(usize, String)>,
pub folds: u32,
}Expand description
The complete scheduler state. Serialized (as JSON) into each checkpoint’s
context_data; byte-stability across resumes is what the
replay-equivalence gate compares.
Fields§
§run_id: String§superstep: u64§phase: Phase§node_gen: Vec<u32>Per node: re-entry generation (0 = first activation).
node_state: Vec<NodeState>§in_res: Vec<BTreeMap<usize, EdgeRes>>Per node: in-edge resolutions AT ITS CURRENT GENERATION, keyed by edge index. Absent = Pending.
edge_fired: Vec<u32>Per edge: total Fired count across the run (max_cycles counts
these — §6.3: “fires in at most n generations per run”).
attempt: Vec<u32>Per node: attempt counter — MONOTONIC across re-entry generations
(never reset), because the journal key is
(run, task_path, node, attempt, effect_seq, kind) and a reset would
mint generation 1 the same keys as generation 0 — the driver would
then answer iteration 2 from iteration 1’s journaled results and the
loop body would execute once, ever. The per-generation retry budget
measures from attempt_base instead.
attempt_base: Vec<u32>Per node: the attempt count when the CURRENT generation began —
attempt - attempt_base is this generation’s attempt number.
context: ValueThe accumulated run state the reducers fold into.
spent: Spent§elapsed_ms: u64Un-charged calendar time (parks, crashes) — reported, never billed.
clock_ms: u64The latest journaled clock reading seen.
wall_open: Option<u64>The active wall segment’s start (None while parked/idle). Wall charges only active segments — open→park and resume→close — so a three-day approval pause costs nothing (§6.7).
paused_at: Option<u64>When the current park began (drives elapsed_ms on resume).
pending_asks: BTreeMap<String, PendingAsk>Parked Client asks by tool_call_id (§6.6 — addressed by id, never
by index).
abstract_flows: BTreeMap<String, AbstractFlow>In-flight abstract-node LLM loops, by node index.
send_tasks: BTreeMap<String, SendTask>Send-spawned tasks by task_path. A target node shows Dispatched
while its batch is unresolved and completes when the batch drains.
spawn_counter: BTreeMap<String, u32>Next spawn ordinal per parent path — monotonic for the whole run, so a re-entered spawner mints fresh task paths and journal keys never collide across generations.
announced_asks: BTreeSet<String>Ask ids already announced in an envelope — a parked run polled again must not re-emit its envelope every step call.
inbox: Vec<Value>Steering messages queued since the last superstep opened, INERT
until one does: an open moves them into context under $inbox.
inputs_seen: u64How many steering messages the run has ever accepted.
cancel: Option<(String, String)>A cancel marker observed (drain in progress).
exhausted: Option<BudgetAxis>A budget axis exhausted mid-superstep (per-dispatch reservation,
§6.7): no new work is emitted; the open superstep’s effects drain,
then the run finishes BudgetExhausted — checkpointed, resumable
after a manifest supersession raises the ceiling.
failed: Option<(usize, String)>Set when fail-fast drain began: the lowest-index permanently-failed node and its detail (deterministic under permutation — chosen at superstep close, not at arrival).
folds: u32Transcript folds performed across the WHOLE run.
Per-flow AbstractFlow.folds disappears with the flow when its node
completes, so by the terminal checkpoint there is nothing left to count
— and “did this workflow keep outgrowing the model’s window?” is a
question about the run, asked after it ended. Carried here so the
run-outcome record can state it and the loop can act on it.