Skip to main content

Task Queue Names

The Temporal Service maintains a set of Task Queues, which Workers poll to see what work needs to be done. Each Task Queue is identified by a name, which is provided to the Temporal Service when launching a Workflow Execution. In this example, the value is included in request to start the Workflow.

Excerpt of code used to start the Workflow in Python

client = await Client.connect("localhost:7233", namespace="default")

# Execute a workflow
result = await client.execute_workflow(
GreetingWorkflow.run,
name,
id="my-workflow",
task_queue="my-task-queue-name",
)

Excerpt of code used to configure the Worker in Python

worker = Worker(
client,
task_queue="my-task-queue-name",
workflows=[GreetingWorkflow],
activities=[activities.say_hello],
)

Since Task Queues are created dynamically when they are first used, a mismatch between these two values does not result in an error. Instead, it will result in the creation of two different Task Queues. Consequently, the Worker will not receive any tasks from the Temporal Service and the Workflow Execution will not progress. Therefore, we recommend that you define the Task Queue name in a constant that is referenced by the Client and Worker if possible, as this will ensure that they always use the same value.

Excerpt of code used to define a constant with the Task Queue name in Python (in a shared.py file)

TASK_QUEUE_NAME = "my-task-queue-name"

Excerpt of code used to start the Workflow, referencing the constant defined with the Task Queue name in Python

from shared import TASK_QUEUE_NAME

...

client = await Client.connect("localhost:7233", namespace="default")

# Execute a workflow
result = await client.execute_workflow(
GreetingWorkflow.run,
name,
id="my-workflow",
task_queue=TASK_QUEUE_NAME,
)

Excerpt of code used to configure the Worker, referencing the constant defined with the Task Queue name in Python

worker = Worker(
client,
task_queue=TASK_QUEUE_NAME,
workflows=[GreetingWorkflow],
activities=[activities.say_hello],
)

However, it’s not always possible to do this, such as when the Client used to start the Workflow is running on another system or is implemented in a different programming language.

Running Multiple Worker Processes

Finally, we recommend running at least two Worker Processes for each Task Queue in a production application, each running on a separate host.

This eliminates the Worker as a single point of failure, because if there are two Worker Processes and one of them crashes, the remaining Worker will recover any executions that were in progress and will continue to handle new ones, too. Running additional Worker Processes will further increase the scalability and availability of your application.