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 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 maxAttempts 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 iterates 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 }}"
        - "{{ taskrun.iteration }}"

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 iterates through the log and if tasks twice as there are two items in values property. The log_parent task logs 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 }}"

The parent variable gives direct access to the first parent, while the parents[INDEX] gives you access to the parent higher up the tree.

Task Run JSON Object Example