liveBook · Manning

Scheduled state

As explained in Build and Orchestrator in Go (From Scratch)

The scheduled state is the lifecycle state of a task for which an execution machine has been selected but execution has not yet started.

The scheduled state marks the point where a manager has selected a machine for a task, but execution has not started. The system may still be sending the task to that machine or waiting for it to start. A task normally reaches Scheduled from Pending, then moves to Running after successful startup or to Failed if startup does not succeed. section 2.1 section 4.6.3

Treat Scheduled as an explicit state in the task lifecycle:

  • Enter it when scheduling assigns the task to a worker. section 4.6.3
  • Remain in it while dispatch or startup is still underway; the transition map permits Scheduled to Scheduled. section 2.1 section 4.6.3
  • Move to Running when the worker successfully starts the task, or to Failed when startup fails. section 4.6.3
  • Reject transitions that are not represented by the state-transition model rather than treating every state change as valid. section 4.6.3
Listing 4.10 The stateTransitionMap map
var stateTransitionMap = map[State][]State{
   Pending:   []State{Scheduled},
   Scheduled: []State{Scheduled, Running, Failed},
   Running:   []State{Running, Completed, Failed},
   Completed: []State{},
   Failed:    []State{},
}

The transition map makes Scheduled's allowed destinations explicit: Scheduled, Running, and Failed. section 4.6.3

Listing 2.1 The State type
package task

type State int

const (
   Pending State = iota
   Scheduled
   Running
   Completed
   Failed
)

The Go State type defines Scheduled alongside Pending, Running, Completed, and Failed. section 2.1

How Build and Orchestrator in Go (From Scratch) covers it

How deep it goes
Defines the state operationally and specifies valid transitions, but does not detail the underlying dispatch protocol.
Examples
Uses a Go state enumeration, a lifecycle diagram, and a state-transition map as concrete representations.
What it assumes
Assumes a task orchestration model with managers and workers, while defining the lifecycle states from their initial meanings.
What you can do after
Diagnose task progression by checking whether scheduling, startup, or failure matches the permitted state transitions.
How it connects
Connects task lifecycle, scheduling, workers, managers, state transitions, and Docker containers.
Cover of Build and Orchestrator in Go (From Scratch)
liveBookmanning.com
Read Build and Orchestrator in Go (From Scratch) on liveBook Get the book at manning.com

This explainer was generated by Manning's knowledge graph from the text of Build and Orchestrator in Go (From Scratch). The section links point to the parts of the book it draws on.