Task Runs

A Task Run is a single run of an individual task within an Execution, where an Execution is a single run of a flow. This means an Execution can have many Task Runs.

Each Task Run has associated data such as:

Execution ID
State
Start Date
End Date

Attempts

Each task run can have one or more attempts. Most task runs will have only one attempt, but you can configure retries for a task. If retries have been configured, a task failure will generate new attempts until the retry maxAttempt or maxDuration threshold is hit.

States

Similar to Executions, Task Runs cans be in a particular state.

State	Description
`CREATED`	The Execution or Task Run is waiting to be processed. This state usually means that the Execution is in a queue and is yet to be started.
`RUNNING`	The Execution or Task Run is currently being processed.
`SUCCESS`	The Execution or Task Run has been completed successfully.
`WARNING`	The Execution or Task Run exhibited unintended behavior, but the execution continued and was flagged with a warning.
`FAILED`	The Execution or Task Run exhibited unintended behavior that caused the execution to fail.
`RETRYING`	The Execution or Task Run is currently being retried.
`RETRIED`	An Execution or Task Run exhibited unintended behavior, stopped, and created a new execution as defined by its flow-level retry policy. The policy was set to the `CREATE_NEW_EXECUTION` behavior.
`KILLING`	A command was issued that asked for the Execution or Task Run to be killed. The system is in the process of killing the associated tasks.
`KILLED`	An Execution or Task Run was killed (upon request), and no more tasks will run.

For a detailed overview of how each Task Run transition through different states, see the States page.

Expression

You can access information about a taskrun using the {{ taskrun }} expression.

This example returns the information from {{ taskrun }}:

yaml

id: taskrun
namespace: company.team

tasks:
  - id: return
    type: io.kestra.plugin.core.debug.Return
    format: "{{ taskrun }}"

The logs show the following:

json

{
    "id": "61TxwXQjkXfwTd4ANK6fhv",
    "startDate": "2024-11-13T14:38:38.355668Z",
    "attemptsCount": 0
}

Task Run Values

Some Flowable Tasks, such as ForEach and ForEachItem, group tasks together. You can use the expression {{ taskrun.value }} to access the value for that task run.

In the example below, foreach will iterate twice over the values [1, 2]:

yaml

id: loop
namespace: company.team

tasks:
  - id: foreach
    type: io.kestra.plugin.core.flow.ForEach
    values: [1, 2]
    tasks:
      - id: log
        type: io.kestra.plugin.core.log.Log
        message:
        - "{{ taskrun }}"
        - "{{ taskrun.value }}"
        - "{{ taskrun.id }}"
        - "{{ taskrun.startDate }}"
        - "{{ taskrun.attemptsCount }}"
        - "{{ taskrun.parentId }}"

This outputs two separate log tasks, one with 1 and the other with 2.

Parent Task Run Values

You can also use the {{ parent.taskrun.value }} expression to access a task run value from a parent task within nested flowable child tasks:

yaml

id: loop
namespace: company.team

tasks:
  - id: foreach
    type: io.kestra.plugin.core.flow.ForEach
    values: [1, 2]
    tasks:
      - id: log
        type: io.kestra.plugin.core.log.Log
        message: "{{ taskrun.value }}"
      - id: if
        type: io.kestra.plugin.core.flow.If
        condition: "{{ true }}"
        then:
          - id: log_parent
            type: io.kestra.plugin.core.log.Log
            message: "{{ parent.taskrun.value }}"

This will iterate through the log and if tasks twice as there are two items in values property. The log_parent task will log the parent task run value as 1 and then 2.

Parent vs. Parents in Nested Flowable Tasks

When using nested Flowable tasks, only the direct parent task is accessible via taskrun.value. To access a parent task higher up the tree, you can use the parent and the parents expressions.

The following flow shows a more complex example with nested flowable parent tasks:

yaml

id: each_switch
namespace: company.team

tasks:
  - id: simple
    type: io.kestra.plugin.core.log.Log
    message:
      - "{{ task.id }}"
      - "{{ taskrun.startDate }}"

  - id: hierarchy_1
    type: io.kestra.plugin.core.flow.ForEach
    values: ["caseA", "caseB"]
    tasks:
      - id: hierarchy_2
        type: io.kestra.plugin.core.flow.Switch
        value: "{{ taskrun.value }}"
        cases:
          caseA:
            - id: hierarchy_2_a
              type: io.kestra.plugin.core.debug.Return
              format: "{{ task.id }}"
          caseB:
            - id: hierarchy_2_b_first
              type: io.kestra.plugin.core.debug.Return
              format: "{{ task.id }}"

            - id: hierarchy_2_b_second
              type: io.kestra.plugin.core.flow.ForEach
              values: ["case1", "case2"]
              tasks:
                - id: switch
                  type: io.kestra.plugin.core.flow.Switch
                  value: "{{ taskrun.value }}"
                  cases:
                    case1:
                      - id: switch_1
                        type: io.kestra.plugin.core.log.Log
                        message:
                          - "{{ parents[0].taskrun.value }}"
                          - "{{ parents[1].taskrun.value }}"
                    case2:
                      - id: switch_2
                        type: io.kestra.plugin.core.log.Log
                        message:
                          - "{{ parents[0].taskrun.value }}"
                          - "{{ parents[1].taskrun.value }}"
  - id: simple_again
    type: io.kestra.plugin.core.log.Log
    message:
      - "{{ task.id }}"
      - "{{ taskrun.startDate }}"