Workflow Run Lifecycle States
The state architecture diagram illustrates the lifecycle of a Workflow & Run Management (represented as an Action in the system) as it transitions through various phases managed by the executor and external events.
The lifecycle begins in the Queued state upon creation. From there, it typically moves through WaitingForResources and Initializing as the system allocates compute resources and performs setup (like pulling container images). Once the task starts executing, it enters the Running state.
Terminal states include Succeeded, Failed, Aborted, and TimedOut. A run can transition to Succeeded directly from Queued if a cache hit is detected. Conversely, it may transition to Failed if validation fails or a permanent error occurs. Retryable failures trigger a transition from Running back to Queued, incrementing the attempt count until the maximum is reached.
Condition Actions introduce a Paused state, where the run awaits an external signal before proceeding to a terminal state. The diagram also captures the ability for a user to Abort a run from any non-terminal state.
Key Architectural Findings:
- Workflow runs are internally represented as Actions, and their lifecycle is governed by the ActionPhase enum.
- The initial state for any new run is ACTION_PHASE_QUEUED.
- Transitions are managed by the TaskActionReconciler, which maps plugin-specific phases to the global ActionPhase.
- Cache hits allow a run to short-circuit directly from Queued to Succeeded.
- Retry logic is implemented by transitioning from Running back to Queued when a retryable failure occurs and attempts remain.
- Terminal states are defined as Succeeded, Failed, Aborted, and TimedOut.
- Condition actions utilize a Paused state to wait for external signals.