Debug your tasks

Debug your app on iExec

Sometimes things don't work out right the first time and you may need to debug your application.

  • Get debug information of a task

iexec task debug <taskid>

It allows anyone to know on-chain and off-chain statuses of the task.

  • Get debug logs of a task

iexec task debug <taskid> --logs

It allows the requester to retrieve application logs produced by workers.

Off-chain statuses

Task statuses

During its execution, a task transitions between different off-chain statuses. Those statuses let you track how a task progresses when it's being executed and makes it easier for you to debug if the execution fails. The transitions between those statuses are as follows.

Please note that, for the sake of simplicity, transitions to the FINAL_DEADLINE_REACHED status have not been pictured. In fact, all statuses except final statuses (FAILED and COMPLETED) can lead to this FINAL_DEADLINE_REACHED status.

As a reminder, tasks have a max execution time, defined by their category. Their final deadlines are defined as follows: deal start time + max execution time. When a task update is triggered on a Scheduler for a non-completed non-failed task while its final deadline is met, then this task status transitions to FINAL_DEADLINE_REACHED.

Below the description of each status:

However, things sometimes don't work as expected. In that case, failure statuses help to understand what went wrong:

Replicate statuses

One task bought by a requester will result in one off-chain task with one or more replicates depending on the level of trust set by the requester. For a given task, each worker involved in the computation will have its own replicate containing the description of the task to compute. The whole computation of a replicate is made of several stages. Each stage completed by a worker will result in an update of its replicate status.

The links between a task to its replicates can be represented as follows:

task1
├── replicate1 (workerX)
├── replicate2 (workerY)
└── replicate3 (workerZ)

A replicate status workflow can follow two different flows:

  1. Usual flow (default): the task is replicated on a number of workers, depending on required trust. The Scheduler has to notify the workers when the consensus is reached. It should also finalize the task on-chain.

  2. Optimized flow (under conditions): the task is finalized by the only worker that has worked on it. It makes the task execution faster and cheaper. However, some limitations apply:

    1. The worker has to be trustworthy. To achieve this point, only TEE tasks are eligible to this workflow.

    2. Callback mode is currently unsupported. iExec strives to remove this limitation.

See the following flowchart for details on their transitions.

Please note that all failed status - pictured in red in the above diagram - finally lead to ABORTED. For the sake of simplicity, this final status has not been represented here.

While the task holds a meta status, each replicate has its own status which can be one of these:

Off-chain replicates failure causes

When a worker fails to complete a replicate, it returns a failure cause. This cause is helpful to understand what went wrong.

Failures detected by the Scheduler

Failures from Worker

A replicate can fail with the following causes:

Common failures

Specific failures for standard tasks

Specific failures for TEE tasks

Last updated