Module disruption_budget 

Disruption-budget gate (new-shape). max_in_flight enforced at dispatch time, summed across all active rollouts whose budgets share a selector (matches the old gate’s “max one workstation in flight, ever” cross-rollout semantics).

LOADBEARING: “in-flight” = {Activating, Soaking} (RFC-0002 §3). Pending is explicitly NOT in-flight — a Pending host has not received its Dispatch yet; counting it as in-flight causes a self-block where a freshly-OpenRollout’d host saturates the budget against its own Pending status and never transitions to Activating. Failed/Reverted/Converged are terminal and also not in-flight.

Within-tick accumulator

Excluding Pending from is_in_flight exposes a within-tick over-commit risk: a single plan_next() tick can emit N QueueDispatches for N Pending hosts, each seeing in_flight = 0 at gate-check time because none have transitioned to Activating yet. With max_in_flight = 1 that’s an N-fold over-commit.

The planner threads tick_dispatched: &HashMap<Selector, u32> through evaluate_for_dispatch and increments the per-budget count after each QueueDispatch. The gate consults in_flight + tick_count against max.

Functions

check

in_flight_count 🔒

is_in_flight 🔒

Type Aliases

BudgetId

Key used by plan_next’s within-tick accumulator. The same Selector value that identifies a budget across rollouts also keys the per-tick counter — one budget identity, one place.