@ancient-wolf-19325 What is the first

WorkflowExecution.Phase

emitted when a workflow starts? I see "ready" mentioned here - https://docs.flyte.org/en/latest/concepts/state_machine.html#workflow-states, but don't see that phase listed here - https://docs.flyte.org/en/latest/protos/docs/core/core.html#ref-flyteidl-core-workflowexecution-phase.

The first

WorkflowExecution.Phase

emitted when a workflow starts is "QUEUED". According to the Flyte state machine documentation, a workflow transitions from "Queued" to "Ready" and then to "Running". However, the "Ready" state is not part of the

WorkflowExecution.Phase

enum. The

WorkflowExecution.Phase

enum values listed in the Flyte core documentation include: - UNDEFINED - QUEUED - RUNNING - SUCCEEDING - SUCCEEDED - FAILING - FAILED - ABORTED - TIMED_OUT - ABORTING Would you like more detail on the state transitions? Sources: - Flyte State Machine Documentation - Flyte Core Documentation 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 Does the

RUNNING

event only ever get emitted once?

No, the

RUNNING

event can be emitted more than once. According to the Flyte issue discussion, there are cases where a task can transition back to the

RUNNING

state after being in a different state, such as

WAITING_FOR_RESOURCES

. Would you like more detail on the scenarios where this can happen? Sources: - Flyte Issue Discussion 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 if I want to get an exact start time for a workflow, which event has that information?

To get the exact start time for a workflow, you should look at the

WorkflowExecutionEvent

with the

RUNNING

phase. According to the FlytePropeller source code, the

RUNNING

event includes the

OccurredAt

timestamp, which indicates when the workflow started running. Would you like more details on how to access this information programmatically? Sources: - FlytePropeller Source Code 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 Does the

QUEUED

event only ever get emitted once?

No, the

QUEUED

event can be emitted more than once. According to the Flyte state machine documentation, a node or task can transition back to the

QUEUED

state under certain conditions, such as retrying after a failure or waiting for resources. Would you like more detail on the scenarios where this can happen? Sources: - Flyte State Machine Documentation 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.