Debug your tasks
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> --chain bellecour
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 --chain bellecour
It allows the requester to retrieve application logs produced by workers.
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_REACHEDstatus have not been pictured. In fact, all statuses except final statuses (
COMPLETED) can lead to this
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
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:
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:
├── 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:
When a worker fails to complete a replicate, it returns a failure cause. This cause is helpful to understand what went wrong.
A replicate can fail with the following causes:
Specific failures for standard tasks
Specific failures for TEE tasks