Tasks

This section documents the built-in task classes available in the LINQ SDK. Tasks are the fundamental building blocks of a workflow. A task represents a unit of work that can be executed, whether that work occurs on an instrument or as custom logic via a CodeTask.

ActionTask Classes

class linq.task.ActionTask(*, id: str = '', description: str = '', dependencies: list[ActionTask | CodeTask | Conditional] = ..., action: str = '', time_estimate: int, instrument_type: str, labware_sources: list[LabwareSource | StoredLabware], labware_outputs: list[LabwareOutput | StoredLabware] = ..., instrument_mappings: list[str] | None = None, available_failure_actions: AvailableFailureActions = ..., skip: bool = False, mock_behaviour: MockBehaviour | None = None, inputs: Inputs = ..., static_arguments: dict[str, Any] | None = None, shared_arguments: dict[str, str] | None = None)

A Task executing an action.

action: str

ID of the action taken (see driver CLI for possible actions for each instrument.)

time_estimate: int

Estimated time to execute the task.

instrument_type: str

Type of the instrument this task runs on.

labware_sources: list[LabwareSource | StoredLabware]

Defines the source of each labware used in this task.

labware_outputs: list[LabwareOutput | StoredLabware]

Outputs of this task. If left empty, defaults to a labware output for each labware source. If no labware sources are defined, this will be empty.

instrument_mappings: list[str] | None

Restrict task to run on an instrument from one of these mappings.

available_failure_actions: AvailableFailureActions

Available actions to be taken in case of failure.

skip: bool

Set to true to skip this task.

mock_behaviour: MockBehaviour | None

Overrides for the behaviour of the task on mock drivers

inputs: Inputs

Inputs to be passed to the task. The key is the name of the input. Can be a TaskOutputReference to the output of another task, a ReferenceData to some stored data, or a literal value.

static_arguments: dict[str, Any] | None

Deprecated, use typed ‘inputs’ field instead

shared_arguments: dict[str, str] | None

Deprecated, use typed ‘inputs’ field instead

forward(*, output: int, destination_slot: int | SlotFillingRule = 1, units_consumed: int | None = None, dependencies: list[ActionTask | CodeTask | Conditional] | None = None) → LabwareSource
forward(*, labware: Labware | None = None, destination_slot: int | SlotFillingRule = 1, units_consumed: int | None = None, dependencies: list[ActionTask | CodeTask | Conditional] | None = None) → LabwareSource

Create a labware source from an output of a previous task.

This can be used to forward previously used labware to another task without having to reference the source task multiple times.

out(output_name: str | None = None) → TaskOutputReference

Reference to the output of this task. If the task has only one output, output_name can be left as None.

An ActionTask represents the execution of an action on a workcell. This could be moving labware, triggering an instrument driver, or a manual operator step. It includes connections to labware sources and outputs.

Failure Actions

Both ActionTask and CodeTask support the optional available_failure_actions parameter. See Error Handling for configuration details and runtime semantics.

CodeTask Classes

class linq.task.CodeTask(*, id: str = '', description: str = '', dependencies: list[Union[ForwardRef('ActionTask'), ForwardRef('CodeTask'), ForwardRef('Conditional')]] = ..., function: linq.task.LuaFunction | linq.task.PythonReferenceFunction, inputs: linq.task.Inputs = ...)
function: LuaFunction | PythonReferenceFunction

The function to be executed.

inputs: Inputs

The inputs to the function. The key is the name of the input. Can be a TaskOutputReference to the output of another task, a ReferenceData to some stored data, or a literal value.

out(output_name: str | None = None) → TaskOutputReference

Reference to the output of this task. If the task has only one output, output_name can be left as None.

A CodeTask allows embedding custom logic into your workflow, either through pre-defined Python functions or Lua scripts.

Data Connector Task Classes

These classes support data transfer and integration within workflows, such as interacting with SFTP endpoints.

ContinuousLoading Classes

Continuous loading tasks enable loading data or labware in a streaming fashion.

Common Task Types and Parameters

Some parameter types used across tasks are documented here:

  • LabwareSource – References labware used by a task.

  • StoredLabware – Declares static labware placement for outputs.

  • LabwareOutput – Specifies where labware ends up after a task.

  • AvailableFailureActions – Defines available failure-handling strategies.

class linq.task.LabwareSource(labware: Labware, destination_slot: int | SlotFillingRule = 1, source_task: ActionTask | ConditionalSourceTask | None = None, dependencies: list[ActionTask | CodeTask | Conditional] = ..., units_consumed: int | None = None)

Specifies the labware required for a task.

labware: Labware

Labware being passed into a task.

destination_slot: int | SlotFillingRule

The instrument slot where the labware will be placed, or the rule for filling slots with labware (batching)

source_task: ActionTask | ConditionalSourceTask | None

ID of the task the labware is being transported from. None for tasks retrieving labware from their initial instrument.

dependencies: list[ActionTask | CodeTask | Conditional]

Additional tasks that have to be completed before the labware for the task is retrieved.

units_consumed: int | None

The number of units of the labware that are consumed in the task. Tied to the total_units of the labware. Leave blank for no units to be consumed.

class linq.task.StoredLabware(labware: linq.labware.Labware, slot: int)
class linq.task.LabwareOutput(labware: Labware, slot: int | OutputSlotFillingRule = 1)

Specifies the output of labware from a task.

labware: Labware

Labware output by the task.

slot: int | OutputSlotFillingRule

The slot the task outputs the labware at. Defaults to 1. If using a SlotFillingRule for the input, use OutputSlotFillingRule for the output to match the slots.

class linq.task.AvailableFailureActions(*, complete_manually: bool = True, retry: bool = True)

Available actions that can be taken by an operator if a task fails.

complete_manually: bool

Allow manually completing the task.

retry: bool

Allow retrying.

Task Dependencies

Tasks can depend on other tasks in the workflow. The dependencies list on a task can include:

  • ActionTask

  • CodeTask

  • Conditional

These types can be mixed to express complex dependency graphs in workflows.

Task-Level Batch Assignment

In addition to defining batching at the workflow level using the batches argument on a Workflow, you can optionally assign a batch value directly to individual tasks.

The batch parameter is supported on:

  • ActionTask

  • CodeTask

  • Conditional

action = ActionTask(
    id="store_samples",
    batch=2,
    ...
)

code = CodeTask(
    id="process_data",
    batch=2,
    ...
)

conditional = Conditional(
    id="validate_results",
    batch=2,
    ...
)

When provided, batch explicitly assigns the task to the specified batch.

Attention

Task-level batch must not be used together with workflow-level batching (for example, setting batches on the Workflow or defining slot ranges intended for multi-batch execution). A workflow must use one batching strategy exclusively.

See Also