Ctrl+K

Task parameters

Task parameters#

You pass the following parameters to the @task decorator:

accelerator#

The accelerator to use for this task. For more information, see Specifying accelerators.

cache#

See Task caching.

cache_serialize#

See Task caching.

cache_version#

See Task caching.

cache_ignore_input_vars#

Input variables that should not be included when calculating the hash for the cache.

container_image#

See Imagespec.

deprecated#

A string that can be used to provide a warning message for deprecated task. Absence / empty str indicates that the task is active and not deprecated

docs#

Documentation about this task.

enable_deck#

If true, this task will output a Flyte Deck which can be used to visualize the task execution (see Decks⬀).

@task(enable_deck=True)
def my_task(my_str: str):
    print("hello {my_str}")

environment#

See Environment variables.

interruptible#

See Interruptible instances.

limits#

See Customizing task resources.

node_dependency_hints#

A list of tasks, launch plans, or workflows that this task depends on. This is only for dynamic tasks/workflows, where Union cannot automatically determine the dependencies prior to runtime. Even on dynamic tasks this is optional, but in some scenarios it will make registering the workflow easier, because it allows registration to be done the same as for static tasks/workflows. For example this is useful to run launch plans dynamically, because launch plans must be registered on Flyteadmin before they can be run. Tasks and workflows do not have this requirement.

@workflow
def workflow0():
    launchplan0 = LaunchPlan.get_or_create(workflow0)
    # Specify node_dependency_hints so that launchplan0
    # will be registered on flyteadmin, despite this being a dynamic task.

@dynamic(node_dependency_hints=[launchplan0])
def launch_dynamically():
    # To run a sub-launchplan it must have previously been registered on flyteadmin.
    return [launchplan0]*10

pod_template#

See Task hardware environment.

pod_template_name#

See Task hardware environment.

requests#

See Customizing task resources

retries#

Number of times to retry this task during a workflow execution. Tasks can define a retry strategy to let the system know how to handle failures (For example: retry 3 times on any kind of error). For more information, see Interruptible instances

There are two kinds of retries system retries and user retries.

secret_requests#

See Secrets

task_config#

Configuration for a specific task type. See the Union Agents documentation and Flyte plugins documentation for the right object to use.

task_resolver#

Provide a custom task resolver.

timeout#

The max amount of time for which one execution of this task should be executed for. The execution will be terminated if the runtime exceeds the given timeout (approximately). To ensure that the system is always making progress, tasks must be guaranteed to end gracefully/successfully. The system defines a default timeout period for the tasks. It is possible for task authors to define a timeout period, after which the task is marked as failure. Note that a timed-out task will be retried if it has a retry strategy defined. The timeout can be handled in the TaskMetadata.

Contents