Executions and Time Limits

Learn about different types of time limits on executions, and how they can affect your executions on the DNAnexus Platform.

Types of Time Limits

On the DNAnexus Platform, executions are subject to two independent time limits: job timeouts, and execution tree expirations.

Job Timeouts

Each job has a timeout setting. This setting denotes the maximum amount of “wall clock time” that the job can spend in the “running” state, i.e. running on the DNAnexus Platform.

If the job is still running when this limit is reached, the job will be terminated.

The default job timeout setting is 30 days, though individual apps may have different timeout settings, as specified by the app’s creator. A job may be given a custom timeout setting.

How Job Timeouts Work

As noted above, job timeouts only apply to the time a job spends in the "running" state.

Job timeouts do not apply to any time a job spends waiting to begin running - as, for example, when a job is waiting for inputs to become available.

Job timeouts also do not apply to the time a job may spend between exiting the “running” state, and entering the “done” state - as, for example, when it is waiting for subjobs to finish.

See this documentation to learn more about on the job lifecycle and job states.

Errors

If a job fails to complete running before reaching its timeout limit, it will be terminated, with the Platform returning JobTimeoutExceeded as the job's failure reason.

Execution Tree Expiration

Each job is part of an execution tree. All jobs in an execution tree must complete running within 30 days of the launch of the tree’s root execution.

After this limit has been reached, all jobs within the execution tree lose the ability to access the Platform.

Note that if an execution tree is restarted, its timeout setting is not reset. Jobs in the tree lose Platform access 30 days after the initial launch (the first try) of the tree’s root execution.

Errors

If an execution tree reaches its time limit, jobs in the tree may not fail right away. If such a job is waiting for inputs or outputs, or if it is running without accessing the Platform, it may remain in that state. Only when the job tries to access the Platform will it fail. Depending on the access pattern, the Platform will return AppInternalError, AppError, or AuthError as the job's failure reason.