A Worker is responsible for polling a Task Queue, dequeueing a Task, executing your code in response to a Task, and responding to the Temporal Cluster with the results.

Worker Processes are external to a Temporal Cluster. Temporal Application developers are responsible for developing Worker Programs and operating Worker Processes. Said another way, the Temporal Cluster (including the Temporal Cloud) doesn't execute any of your code (Workflow and Activity Definitions) on Temporal Cluster machines. The Cluster is solely responsible for orchestrating State Transitions and providing Tasks to the next available Worker Entity.

A Worker Process can be both a Workflow Worker Process and an Activity Worker Process. Haskell the ability to have multiple Worker Entities in a single Worker Process.

A single Worker Entity can listen to only a single Task Queue. But if a Worker Process has multiple Worker Entities, the Worker Process could be listening to multiple Task Queues.

Wait for a worker to exit. This waits for both the workflow and activity loops to complete.

Any exceptions thrown by the workflow or activity loops will be rethrown.

This function is generally not needed, as shutdown will wait for the worker to exit.

Shut down a worker. This will initiate a graceful shutdown of the worker, waiting for all in-flight tasks to complete before finalizing the shutdown.

Link a worker to the current thread. This will cause uncaught worker exceptions to be rethrown in the current thread.

If the worker has both workflow and activity definitions registered, this will link both the workflow and activity loops. If one of the loops fails, the worker will initiate graceful shutdown (but not block) before rethrowing the exception.

Replace the environment for activities run within a Worker. This is generally not needed, but can be useful for reusing a Worker under test.

Turn a configuration block into the final configuration.

Run a worker in replay mode, feeding a history to the worker in order to ensure that the worker execution still works as expected.

Subscribe to evictions from the worker. This is not generally needed, but can be useful for debugging.

Subscribe to evictions from the worker. This is not generally needed, but can be useful for debugging.

Set the logger for the worker. This is used to log messages from the worker.

Set the tracer provider for the worker. This is used to trace the worker's internal activity.

The namespace that all workflows and activities will be registered in for this worker.

If you need to register workflows and activities in multiple namespaces, you will need to start multiple workers. Multiple workers may run in the same process.

A temporal worker, whether polling for workflows or activities, does so by polling a specific "Task Queue".

Any time there is a new activity task or workflow task that needs to be performed by a worker, it'll be queued in a specific task queue.

A string that should be unique to the exact worker code/binary being executed.

This is used to uniquely identify the worker's code for a handful of purposes, including the worker versioning feature if you have opted into that with useVersioning. It will also populate the binaryChecksum field on older servers.

N.B. this is not the same as the worker's identity, which is a string that identifies the worker instance. The identity is used to identify the worker instance in logs and in the Temporal UI. The buildId is used to identify the exact version of the code and its dependencies. In e.g. Nix, the executable path in the Nix store would be a useful buildId.

Maximum number of Activity tasks to poll concurrently.

Increase this setting if your Worker is failing to fill in all of its maxConcurrentActivityTaskExecutions slots despite a backlog of Activity Tasks in the Task Queue (ie. due to network latency). Can't be higher than maxConcurrentActivityTaskExecutions.

How long a workflow task is allowed to sit on the sticky queue before it is timed out and moved to the non-sticky queue where it may be picked up by any worker.

Longest interval for throttling activity heartbeats

Limits the number of Activities per second that this Worker will process. (Does not limit the number of Local Activities.) The Worker will not poll for new Activities if by doing so it might receive and execute an Activity which would cause it to exceed this limit. Must be a positive number.

If unset, no rate limiting will be applied to Worker's Activities. (tctl task-queue describe will display the absence of a limit as 100,000.)

Sets the maximum number of activities per second the task queue will dispatch, controlled server-side. Note that this only takes effect upon an activity poll request. If multiple workers on the same queue have different values set, they will thrash with the last poller winning.

If unset, no rate limiting will be applied to the task queue.

Time to wait for pending tasks to drain after shutdown was requested.

In-flight activities will be cancelled after this period and their current attempt will be resolved as failed if they confirm cancellation (by throwing a CancelledFailure or AbortError).

A Workflow Id is a customizable, application-level identifier for a Workflow Execution that is unique to an Open Workflow Execution within a Namespace.