Table of Contents

Namespace Temporalio.Api.TaskQueue.V1



Assignment rules are applied to new Workflow and Activity executions at schedule time to assign them to a Build ID.

Assignment rules will not be used in the following cases:

  • Child Workflows or Continue-As-New Executions who inherit their parent/previous Workflow's assigned Build ID (by setting the inherit_build_id flag - default behavior in SDKs when the same Task Queue is used.)
  • An Activity that inherits the assigned Build ID of its Workflow (by setting the use_workflow_build_id flag - default behavior in SDKs when the same Task Queue is used.)

In absence of (applicable) redirect rules (CompatibleBuildIdRedirectRules) the task will be dispatched to Workers of the Build ID determined by the assignment rules (or inherited). Otherwise, the final Build ID will be determined by the redirect rules.

Once a Workflow completes its first Workflow Task in a particular Build ID it stays in that Build ID regardless of changes to assignment rules. Redirect rules can be used to move the workflow to another compatible Build ID.

When using Worker Versioning on a Task Queue, in the steady state, there should typically be a single assignment rule to send all new executions to the latest Build ID. Existence of at least one such "unconditional" rule at all times is enforces by the system, unless the force flag is used by the user when replacing/deleting these rules (for exceptional cases).

During a deployment, one or more additional rules can be added to assign a subset of the tasks to a new Build ID based on a "ramp percentage".

When there are multiple assignment rules for a Task Queue, the rules are evaluated in order, starting from index 0. The first applicable rule will be applied and the rest will be ignored.

In the event that no assignment rule is applicable on a task (or the Task Queue is simply not versioned), the tasks will be dispatched to an unversioned Worker.


Reachability of tasks for a worker by build id, in one or more task queues.


These rules apply to tasks assigned to a particular Build ID (source_build_id) to redirect them to another compatible Build ID (target_build_id).

It is user's responsibility to ensure that the target Build ID is compatible with the source Build ID (e.g. by using the Patching API).

Most deployments are not expected to need these rules, however following situations can greatly benefit from redirects:

  • Need to move long-running Workflow Executions from an old Build ID to a newer one.
  • Need to hotfix some broken or stuck Workflow Executions.

In steady state, redirect rules are beneficial when dealing with old Executions ran on now-decommissioned Build IDs:

  • To redirecting the Workflow Queries to the current (compatible) Build ID.
  • To be able to Reset an old Execution so it can run on the current (compatible) Build ID.

Redirect rules can be chained.


Used by the worker versioning APIs, represents an unordered set of one or more versions which are considered to be compatible with each other. Currently the versions are always worker build IDs.


Holder for reflection information generated from temporal/api/taskqueue/v1/message.proto




Only applies to activity task queues


Reachability of tasks for a worker on a single task queue.


For workflow task queues, we only report the normal queue stats, not sticky queues. This means the stats reported here do not count all workflow tasks. However, because the tasks queued in sticky queues only remain valid for a few seconds, the inaccuracy becomes less significant as the backlog age grows.


Deprecated. Use InternalTaskQueueStatus. This is kept until DescribeTaskQueue supports legacy behavior.


Used for specifying versions the caller is interested in.




Enum of possible cases for the "ramp" oneof.