Skip to main content
The scheduler decides whether, when and in what order an execution may begin. It grants a slot to each execution, or queues or refuses the start. The execution id is handed out only after a slot is granted, so two requests racing for the last slot can never both succeed.

​
Limits

All limits are off by default. A start that does not fit waits with status QUEUED, or is refused with HTTP 429, depending on on-limit.

​
Queue order

When a slot frees up, the next start is chosen by:
  1. Priority: the start payload key yukta.priority (a number, higher first, default 0).
  2. Fairness: the session with the fewest running executions goes first, oldest first on a tie. One busy session cannot starve others.
  3. Arrival order.

​
Restarts and resumes

Restarting a finished execution, restarting from a node and resuming take their slot the same way as a new start, before the new id is reported. Restarting an execution that is still running keeps the old behaviour: the old execution holds its slot until it ends. Child executions of sub-workflows run on their parent’s slot.

​
Idempotent start

A client that retries a start after a network failure gets the first execution back instead of starting a second one. Send an Idempotency-Key header:

​
Change limits while running

Operators can change the limits and a queued execution’s priority without a restart:
  • Changing limits needs role ADMIN. The new limits are recorded in the execution log, and on startup the newest recorded change is reapplied, so the log wins over configuration from then on.
  • Changing a priority needs role OPERATOR and works only while the execution is QUEUED.
  • Both pass the reviewers and are audited with the actor.

​
What you see

​
Shutdown

On shutdown nothing new is admitted, queued starts are refused, and running executions get yukta.execution.shutdown-timeout to finish.

​
Limits and defaults

One scheduler lives in one server process. Queue positions and slots are lost if the server crashes; the start was logged first, so the execution is marked ABORTED on boot and can be recovered. A standby server in a high-availability pair refuses every start with 503; see High availability.