Worker Task

Prerequisites

Before adding a Worker task to a workflow, you should complete the following:

• Create and run a worker that polls Conductor and executes the Worker task.
• (Recommended) Create the task definition in Conductor (UI or API) so the workflow can reference it by name. The Worker task name in your workflow must match the Task Definition name you created in Conductor. If no task definition exists, Conductor uses a default task definition with default retry, timeout, and rate limit settings.

For a full guide on how to use workers, refer to Workers.

Task parameters

To configure a Worker task, set inputParameters to the inputs your worker expects. The inputs can be passed as a dynamic variable.

You can also define default inputs for the task using input templates. An input template is a set of key-value pairs defined in the task definition (inputTemplate) that is passed to every instance of the task across all workflows. This is useful for inputs that rarely change, such as a region or a default configuration value, so you do not have to repeat them in every workflow.

When the task is scheduled, Conductor merges the input template with inputParameters:

• If a key is missing from inputParameters, the value from the input template is used.
• If a key in inputParameters resolves to null, the value from the input template is used.
• Otherwise, the value in inputParameters takes precedence.

Set inputTemplate in the task definition, either in the task definition JSON or in the Conductor UI under Definitions > Task > (your task) > Task input template. See an example of using input templates.

The following are generic configuration parameters that can be applied to the task and are not specific to the Worker task.

Caching parameters

You can cache task outputs using the following parameters. Only the outputs of completed tasks are cached. If a cached output exists for the computed cache key, the task is completed immediately with the cached output, without being sent to a worker, and the output includes "_cachedResponse": true. Refer to Caching Task Outputs for a full guide.

Parameter	Description	Required/ Optional
cacheConfig.ttlInSecond	The time to live in seconds, which is the duration for the output to be cached.	Required if using cacheConfig.
cacheConfig.key	The cache key is a unique identifier for the cached output and must be constructed exclusively from the task’s input parameters. It can be a string concatenation that contains the task’s input keys, such as ${uri}-${method} or re_${uri}_${method}.	Required if using cacheConfig.

Schema parameters

You can enforce input/output validation for the task using the following parameters. Refer to Schema Validation for a full guide.

Parameter	Description	Required/ Optional
taskDefinition.enforceSchema	Whether to enforce schema validation for task inputs/outputs. Set to true to enable validation.	Optional.
taskDefinition.inputSchema	The name and type of the input schema to be associated with the task. If not set, task inputs are not validated.	Optional. Used only if enforceSchema is set to true.
taskDefinition.outputSchema	The name and type of the output schema to be associated with the task. If not set, task outputs are not validated.	Optional. Used only if enforceSchema is set to true.

Other generic parameters

Here are other parameters for configuring the task behavior.

Parameter	Description	Required/ Optional
optional	Whether the task is optional. If set to true, any task failure is ignored, and the workflow continues with the task status updated to COMPLETED_WITH_ERRORS. However, the task must reach a terminal state. If the task remains incomplete, the workflow waits until it reaches a terminal state before proceeding.	Optional.
startDelay	The time in seconds to wait before the task is made available for polling by a worker. The default value is 0.	Optional.

Task configuration

This is the task configuration for a Worker task.

{
  "name": "sayHello",
  "taskReferenceName": "sayHello_ref",
  "type": "SIMPLE",
  "inputParameters": {
    "firstName": "${workflow.input.firstName}",
    "lastName": "${workflow.input.lastName}"
  }
}

Task output

The Worker task will return the output defined in your worker code.

Examples

Using input templates

In this example, the task input template sets default values for region and retries:

{
  "name": "sayHello",
  "inputTemplate": {
    "region": "us-east-1",
    "retries": 3
  }
}

In the workflow, the Worker task sets its own value for retries and adds a firstName input:

{
  "name": "sayHello",
  "taskReferenceName": "sayHello_ref",
  "type": "SIMPLE",
  "inputParameters": {
    "firstName": "${workflow.input.firstName}",
    "retries": 5
  }
}

When the workflow runs with the input {"firstName": "John"}, the worker receives the following input:

{
  "firstName": "John",
  "region": "us-east-1",
  "retries": 5
}

Here is how each input is resolved:

• region is us-east-1 because it is not set in inputParameters, so the value from the input template is used.
• retries is 5, not 3, because it is set in both places, and the value in inputParameters always takes precedence over the input template. The template value 3 is only used when the task does not set retries or when its value resolves to null.
• firstName is John because it is resolved from the workflow input (${workflow.input.firstName}). It does not exist in the input template. If it had resolved to null and the input template defined firstName, the template value would be used instead.

Related pages

• Task Reference