+ 
+
+
## States
-A job can be in one of the following states:
+Every Job is always in exactly one of the following states:
+
+
+ 
Submitted
+
+ Submitted 
Submitted The Job hasn't started yet, all it's tasks are queued and it wasn't canceled by the user.
+
+ 
Running
+
+ Running 
Running At least one task of the job is currently running.
+
+ 
Started
+
+ Started 
Started The job has started, some tasks are already `COMPUTED`, but others are still `QUEUED`, waiting for an [eligible task runner](/workflows/concepts/task-runners#task-selection) to pick them up. However no task is currently `RUNNING`.
+
+ 
Completed
+
+ Completed 
Completed The job has successfully completed. Every task of the job succeeded and is `COMPUTED`.
+
+ 
Failed
+
+ Failed 
Failed At least one task of the job has failed, causing the execution of the remaining tasks to be halted. You can [retry](#retries) the job to resume execution from the point of failure.
+
+ 
Canceled
+
-- `QUEUED`: the job is queued and waiting for execution
-- `STARTED`: at least one task of the job has been started
-- `COMPLETED`: all tasks of the job have been completed
+ Canceled 
Canceled The job was canceled upon user request. You can [retry](#retries) the job to resume execution from the point of cancellation.
+
-The color codes for task states are:
-
-| Task State | Color | Description |
-|------------|-------|-------------|
-| Queued | SalmonYellow | The task is queued and waiting for execution. |
-| Running | Blue | The task is currently being executed. |
-| Computed | Green | The task has successfully been computed. If a task is computed, and all it's sub-tasks are also computed, the task is considered completed. |
-| Failed | Red | The task has been executed but encountered an error. |
-
Below is another visualization of a job currently being executed by multiple task runners.
@@ -246,9 +271,9 @@ Below is another visualization of a job currently being executed by multiple tas
-This visualization shows:
+From the diagram, the following can be inferred:
-- The root task, `MyTask`, has executed and spawned three sub-tasks.
+- The root task, `MyTask`, has been executed, is marked as `COMPUTED` and submitted three sub-tasks.
- At least three task runners are available, as three tasks currently are executed simultaneously.
- The `SubTask` that is still executing has not generated any sub-tasks yet, as sub-tasks are queued for execution only after the parent task finishes and becomes computed.
- The queued `DependentTask` requires the `LeafTask` to complete before it can be executed.
diff --git a/workflows/concepts/tasks.mdx b/workflows/concepts/tasks.mdx
index 2efb8f9..d5697cf 100644
--- a/workflows/concepts/tasks.mdx
+++ b/workflows/concepts/tasks.mdx
@@ -354,18 +354,118 @@ In total, six tasks are executed: the `DownloadRandomDogImages` task and five `D
Check out [job_client.display](/workflows/concepts/jobs#visualization) to learn how this visualization was automatically generated from the task executions.
-Currently, a limit of `64` subtasks per task is in place to discourage creating workflows where individual parent tasks submit a large number of subtasks, which can lead to performance issues since those parent tasks are not parallelized. If you need to submit more than `64` subtasks, consider using [recursive subtask submission](#recursive-subtasks) instead.
+## Task States
-## Recursive subtasks
+Every task goes through a set of states during its lifetime. When submitted, either as a job or as a subtask, it starts in the `QUEUED` state and transitions to `RUNNING` when a task runner picks it up. If the task executes successfully, it transitions to `COMPUTED`. If the task fails, it transitions to `FAILED`.
+As soon as all subtasks of a task are also `COMPUTED`, the task is considered `COMPLETED`, allowing dependent tasks to be executed.
+The table below summarizes the different task states and their meanings.
+
+| Task State | Description |
+|------------|-------------|
+| **Queued** | The task is queued and waiting for execution. Any [eligible](/workflows/concepts/task-runners#task-selection) task runner can pick it up and execute it, as soon as it's parent task is `COMPUTED` and all it's dependencies are `COMPLETED`. |
+| **Running** | The task is currently being executed by a task runner. |
+| **Computed** | The task has successfully been computed, but still has outstanding subtasks. |
+| **Completed** | The task has successfully been computed, and all it's subtasks are also computed, making it `COMPLETED`. This is the final state of a task. Only once a task has been `COMPLETED`, dependent tasks can be executed. |
+| **Failed** | The task has been executed but encountered an error. |
+
+
+
+
+
+
+## Map-Reduce Pattern
+Often times the input to a task is a list, with elements that should then be **mapped** to individual subtasks, whose results are later aggregated in a **reduce** step. This pattern is commonly known as [MapReduce](https://en.wikipedia.org/wiki/MapReduce) and a common pattern in workflows. In Tilebox, the reduce step is typically defined as a separate task that depends on all the map tasks.
+
+For example, the workflow below applies this pattern to a list of numbers to calculate the sum of all squares of the numbers. The `Square` task takes a single number and squares it, and the `Sum` task reduces the list of squared numbers to a single sum.
+
+
+ 
+
+
+## Recursive subtasks
+
+Tasks can not only submit other tasks as subtasks, but also instances of themselves. This allows for a recursive breakdown of a task into smaller chunks. Such recursive decomposition algorithms are referred to as [divide and conquer algorithms](https://en.wikipedia.org/wiki/Divide-and-conquer_algorithm).
For example, the `RecursiveTask` below is a valid task that submits smaller instances of itself as subtasks.
+