EDU-3427: Project Nova: Worker pg break out including redirects and a…

…nchors (#3270)

* restucturing

* adding in intros

* running yarn format

* changing task queue

* redirects for activity task execution and task queue

* redirects for workflow task and workflow task execution

* changing redirects for nexus tasks

* changing redirects for activity tasks

* restructuring

* redirecting task routing

* worker versioning redirects

* legacy worker versioning redirect

* redirect sticky execution

* redirects for worker entity

* redirecting task definition

* worker session and task queue redirects

* updating anchors on workers page

---------

Co-authored-by: Brian MacDonald <[email protected]>

docs/cli/task-queue.mdx

@@ -15,12 +15,12 @@ tags:
   - Temporal CLI
 ---
 
-Task Queue commands allow operations to be performed on [Task Queues](/workers#task-queue).
+Task Queue commands allow operations to be performed on [Task Queues](/task-queue).
 To run a Task Queue command, run `temporal task-queue [command] [command options]`
 
 ## describe
 
-The `temporal task-queue describe` command provides [poller](/develop/worker-performance#poller-count) information for a given [Task Queue](/workers#task-queue).
+The `temporal task-queue describe` command provides [poller](/develop/worker-performance#poller-count) information for a given [Task Queue](/task-queue).
 
 The [Server](/clusters#temporal-server) records the last time of each poll request.
 A `LastAccessTime` value in excess of one minute can indicate the Worker is at capacity (all Workflow and Activity slots are full) or that the Worker has shut down.
@@ -73,7 +73,7 @@ Use the following options to change the behavior of this command.
 
 ## list-partition
 
-The `temporal task-queue list-partition` command displays the partitions of a [Task Queue](/workers#task-queue), along with the matching node they are assigned to.
+The `temporal task-queue list-partition` command displays the partitions of a [Task Queue](/task-queue), along with the matching node they are assigned to.
 
 Use the following options to change the command's behavior.
 

docs/cli/workflow.mdx

@@ -50,7 +50,7 @@ Workflow commands use this syntax:
 The `temporal workflow cancel` command cancels a [Workflow Execution](/workflows#workflow-execution).
 
 Canceling a running Workflow Execution records a [`WorkflowExecutionCancelRequested` event](/references/events#workflowexecutioncancelrequested) in the [Event History](/workflows#event-history).
-A new [Workflow Task](/workers#workflow-task) will be scheduled, and the Workflow Execution performs cleanup work.
+A new [Workflow Task](/tasks#workflow-task) will be scheduled, and the Workflow Execution performs cleanup work.
 
 `temporal workflow cancel --workflow-id=meaningful-business-id`
 

docs/develop/dotnet/core-application.mdx

@@ -230,7 +230,7 @@ A single argument is limited to a maximum size of 2 MB.
 And the total size of a gRPC message, which includes all the arguments, is limited to a maximum of 4 MB.
 
 Also, keep in mind that all Payload data is recorded in the [Workflow Execution Event History](/workflows#event-history) and large Event Histories can affect Worker performance.
-This is because the entire Event History could be transferred to a Worker Process with a [Workflow Task](/workers#workflow-task).
+This is because the entire Event History could be transferred to a Worker Process with a [Workflow Task](/tasks#workflow-task).
 
 Some SDKs require that you pass context objects, others do not.
 When it comes to your application data—that is, data that is serialized and encoded into a Payload—we recommend that you use a single object as an argument that wraps the application data passed to Activities.
@@ -246,7 +246,7 @@ Technically this can be multiple parameters, but Temporal strongly encourages a
 
 Calls to spawn [Activity Executions](/activities#activity-execution) are written within a [Workflow Definition](/workflows#workflow-definition).
 The call to spawn an Activity Execution generates the [ScheduleActivityTask](/references/commands#scheduleactivitytask) Command.
-This results in the set of three [Activity Task](/workers#activity-task) related Events ([ActivityTaskScheduled](/references/events#activitytaskscheduled), [ActivityTaskStarted](/references/events#activitytaskstarted), and ActivityTask[Closed])in your Workflow Execution Event History.
+This results in the set of three [Activity Task](/tasks#activity-task) related Events ([ActivityTaskScheduled](/references/events#activitytaskscheduled), [ActivityTaskStarted](/references/events#activitytaskstarted), and ActivityTask[Closed])in your Workflow Execution Event History.
 
 A single instance of the Activities implementation is shared across multiple simultaneous Activity invocations.
 Activity implementation code should be _idempotent_.
@@ -293,7 +293,7 @@ The Activity result is the returned in the task from the `ExecuteActivityAsync`
 The [Worker Process](/workers#worker-process) is where Workflow Functions and Activity Functions are executed.
 
 - Each [Worker Entity](/workers#worker-entity) in the Worker Process must register the exact Workflow Types and Activity Types it may execute.
-- Each Worker Entity must also associate itself with exactly one [Task Queue](/workers#task-queue).
+- Each Worker Entity must also associate itself with exactly one [Task Queue](/task-queue).
 - Each Worker Entity polling the same Task Queue must be registered with the same Workflow Types and Activity Types.
 
 A [Worker Entity](/workers#worker-entity) is the component within a Worker Process that listens to a specific Task Queue.

docs/develop/dotnet/failure-detection.mdx

@@ -87,8 +87,8 @@ Each Activity Timeout controls the maximum duration of a different aspect of an
 The following Timeouts are available in the Activity Options.
 
 - **[Schedule-To-Close Timeout](/encyclopedia/detecting-activity-failures#schedule-to-close-timeout):** is the maximum amount of time allowed for the overall [Activity Execution](/activities#activity-execution).
-- **[Start-To-Close Timeout](/encyclopedia/detecting-activity-failures#start-to-close-timeout):** is the maximum time allowed for a single [Activity Task Execution](/workers#activity-task-execution).
-- **[Schedule-To-Start Timeout](/encyclopedia/detecting-activity-failures#schedule-to-start-timeout):** is the maximum amount of time that is allowed from when an [Activity Task](/workers#activity-task) is scheduled to when a [Worker](/workers#worker) starts that Activity Task.
+- **[Start-To-Close Timeout](/encyclopedia/detecting-activity-failures#start-to-close-timeout):** is the maximum time allowed for a single [Activity Task Execution](/tasks#activity-task-execution).
+- **[Schedule-To-Start Timeout](/encyclopedia/detecting-activity-failures#schedule-to-start-timeout):** is the maximum amount of time that is allowed from when an [Activity Task](/tasks#activity-task) is scheduled to when a [Worker](/workers#worker) starts that Activity Task.
 
 An Activity Execution must have either the Start-To-Close or the Schedule-To-Close Timeout set.
 
@@ -149,7 +149,7 @@ throw new ApplicationFailureException(
 
 An [Activity Heartbeat](/encyclopedia/detecting-activity-failures#activity-heartbeat) is a ping from the [Worker Process](/workers#worker-process) that is executing the Activity to the [Temporal Service](/clusters).
 Each Heartbeat informs the Temporal Service that the [Activity Execution](/activities#activity-execution) is making progress and the Worker has not crashed.
-If the Temporal Service does not receive a Heartbeat within a [Heartbeat Timeout](/encyclopedia/detecting-activity-failures#heartbeat-timeout) time period, the Activity will be considered failed and another [Activity Task Execution](/workers#activity-task-execution) may be scheduled according to the Retry Policy.
+If the Temporal Service does not receive a Heartbeat within a [Heartbeat Timeout](/encyclopedia/detecting-activity-failures#heartbeat-timeout) time period, the Activity will be considered failed and another [Activity Task Execution](/tasks#activity-task-execution) may be scheduled according to the Retry Policy.
 
 Heartbeats may not always be sent to the Temporal Service—they may be [throttled](/encyclopedia/detecting-activity-failures#throttling) by the Worker.
 

docs/develop/dotnet/temporal-client.mdx

@@ -93,7 +93,7 @@ A request to spawn a Workflow Execution causes the Temporal Service to create th
 The Temporal Service then creates the first Workflow Task, resulting in the first [WorkflowTaskScheduled](/references/events#workflowtaskscheduled) Event.
 
 To start a Workflow Execution in .NET, use either the `StartWorkflowAsync()` or `ExecuteWorkflowAsync()` methods in the Client.
-You must set a [Workflow Id](/workflows#workflow-id) and [Task Queue](/workers#task-queue) in the `WorkflowOptions` given to the method.
+You must set a [Workflow Id](/workflows#workflow-id) and [Task Queue](/task-queue) in the `WorkflowOptions` given to the method.
 
 ```csharp
 var result = await client.ExecuteWorkflowAsync(

docs/develop/go/core-application.mdx

@@ -454,7 +454,7 @@ A single argument is limited to a maximum size of 2 MB.
 And the total size of a gRPC message, which includes all the arguments, is limited to a maximum of 4 MB.
 
 Also, keep in mind that all Payload data is recorded in the [Workflow Execution Event History](/workflows#event-history) and large Event Histories can affect Worker performance.
-This is because the entire Event History could be transferred to a Worker Process with a [Workflow Task](/workers#workflow-task).
+This is because the entire Event History could be transferred to a Worker Process with a [Workflow Task](/tasks#workflow-task).
 
 {/* TODO link to gRPC limit section when available */}
 
@@ -557,7 +557,7 @@ func main() {
 
 Calls to spawn [Activity Executions](/activities#activity-execution) are written within a [Workflow Definition](/workflows#workflow-definition).
 The call to spawn an Activity Execution generates the [ScheduleActivityTask](/references/commands#scheduleactivitytask) Command.
-This results in the set of three [Activity Task](/workers#activity-task) related Events ([ActivityTaskScheduled](/references/events#activitytaskscheduled), [ActivityTaskStarted](/references/events#activitytaskstarted), and ActivityTask[Closed])in your Workflow Execution Event History.
+This results in the set of three [Activity Task](/tasks#activity-task) related Events ([ActivityTaskScheduled](/references/events#activitytaskscheduled), [ActivityTaskStarted](/references/events#activitytaskstarted), and ActivityTask[Closed])in your Workflow Execution Event History.
 
 A single instance of the Activities implementation is shared across multiple simultaneous Activity invocations.
 Activity implementation code should be _idempotent_.
@@ -691,7 +691,7 @@ if err != nil {
 }
 ```
 
-- [What is a Task Queue](/workers#task-queue)
+- [What is a Task Queue](/task-queue)
 
 #### ScheduleToCloseTimeout
 

docs/develop/go/failure-detection.mdx

@@ -97,8 +97,8 @@ Each Activity timeout controls the maximum duration of a different aspect of an
 The following timeouts are available in the Activity Options.
 
 - **[Schedule-To-Close Timeout](/encyclopedia/detecting-activity-failures#schedule-to-close-timeout):** is the maximum amount of time allowed for the overall [Activity Execution](/activities#activity-execution).
-- **[Start-To-Close Timeout](/encyclopedia/detecting-activity-failures#start-to-close-timeout):** is the maximum time allowed for a single [Activity Task Execution](/workers#activity-task-execution).
-- **[Schedule-To-Start Timeout](/encyclopedia/detecting-activity-failures#schedule-to-start-timeout):** is the maximum amount of time that is allowed from when an [Activity Task](/workers#activity-task) is scheduled to when a [Worker](/workers#worker) starts that Activity Task.
+- **[Start-To-Close Timeout](/encyclopedia/detecting-activity-failures#start-to-close-timeout):** is the maximum time allowed for a single [Activity Task Execution](/tasks#activity-task-execution).
+- **[Schedule-To-Start Timeout](/encyclopedia/detecting-activity-failures#schedule-to-start-timeout):** is the maximum amount of time that is allowed from when an [Activity Task](/tasks#activity-task) is scheduled to when a [Worker](/workers#worker) starts that Activity Task.
 
 An Activity Execution must have either the Start-To-Close or the Schedule-To-Close Timeout set.
 
@@ -189,7 +189,7 @@ return temporal.NewApplicationErrorWithOptions(fmt.Sprintf("Something bad happen
 
 An [Activity Heartbeat](/encyclopedia/detecting-activity-failures#activity-heartbeat) is a ping from the [Worker Process](/workers#worker-process) that is executing the Activity to the [Temporal Service](/clusters).
 Each Heartbeat informs the Temporal Service that the [Activity Execution](/activities#activity-execution) is making progress and the Worker has not crashed.
-If the Temporal Service does not receive a Heartbeat within a [Heartbeat Timeout](/encyclopedia/detecting-activity-failures#heartbeat-timeout) time period, the Activity will be considered failed and another [Activity Task Execution](/workers#activity-task-execution) may be scheduled according to the Retry Policy.
+If the Temporal Service does not receive a Heartbeat within a [Heartbeat Timeout](/encyclopedia/detecting-activity-failures#heartbeat-timeout) time period, the Activity will be considered failed and another [Activity Task Execution](/tasks#activity-task-execution) may be scheduled according to the Retry Policy.
 
 Heartbeats may not always be sent to the Temporal Service—they may be [throttled](/encyclopedia/detecting-activity-failures#throttling) by the Worker.
 

docs/develop/go/schedules.mdx

@@ -81,7 +81,7 @@ The Temporal Service doesn't guarantee when this removal will happen.
 
 **How to Backfill a Schedule for a Workflow using the Go SDK.**
 
-Backfilling a Schedule executes [Workflow Tasks](/workers#workflow-task) ahead of the Schedule's specified time range.
+Backfilling a Schedule executes [Workflow Tasks](/tasks#workflow-task) ahead of the Schedule's specified time range.
 This is useful for executing a missed or delayed Action, or for testing the Workflow ahead of time.
 
 To backfill a Schedule in Go, use `Backfill()` on `ScheduleHandle`.

docs/develop/go/sessions.mdx

@@ -24,7 +24,7 @@ This page shows how to do the following:
 
 :::
 
-A Worker Session is a feature that provides a straightforward API for [Task Routing](/workers#task-routing) to ensure that Activity Tasks are executed with the same Worker without requiring you to manually specify Task Queue names.
+A Worker Session is a feature that provides a straightforward API for [Task Routing](/task-routing) to ensure that Activity Tasks are executed with the same Worker without requiring you to manually specify Task Queue names.
 
 ## Enable Worker Sessions {#enable-sessions}
 

docs/develop/go/temporal-client.mdx

@@ -244,7 +244,7 @@ workflowRun, err := c.ExecuteWorkflow(context.Background(), workflowOptions, "Yo
 
 **How to set a Workflow's Task Queue using the Go SDK**
 
-In most SDKs, the only Workflow Option that must be set is the name of the [Task Queue](/workers#task-queue).
+In most SDKs, the only Workflow Option that must be set is the name of the [Task Queue](/task-queue).
 
 For any code to execute, a Worker Process must be running that contains a Worker Entity that is polling the same Task Queue name.
 
@@ -266,7 +266,7 @@ if err != nil {
 ```
 
 You can configure Task Queues that are host-specific, Worker-specific or Workflow-specific to distribute your application load.
-For more information, refer to [Task Queues Processing Tuning](/develop/worker-performance#task-queues-processing-tuning) and [Worker Versioning](https://docs.temporal.io/workers#worker-versioning).
+For more information, refer to [Task Queues Processing Tuning](/develop/worker-performance#task-queues-processing-tuning) and [Worker Versioning](https://docs.temporal.io/worker-versioning).
 
 ### Set custom Workflow Id {#workflow-id}
 
@@ -719,7 +719,7 @@ You can start a Workflow Execution on a regular schedule with [the CronSchedule
 
 ### How to set a Workflow's Task Queue {#set-task-queue}
 
-In most SDKs, the only Workflow Option that must be set is the name of the [Task Queue](/workers#task-queue).
+In most SDKs, the only Workflow Option that must be set is the name of the [Task Queue](/task-queue).
 
 For any code to execute, a Worker Process must be running that contains a Worker Entity that is polling the same Task Queue name.
 

docs/develop/go/versioning.mdx

@@ -182,7 +182,7 @@ See the [Pre-release README](https://github.com/temporalio/temporal/blob/main/do
 :::
 
 A Build ID corresponds to a deployment. If you don't already have one, we recommend a hash of the code--such as a Git SHA--combined with a human-readable timestamp.
-To use [Worker Versioning](/workers#worker-versioning), you need to pass a Build ID to your Go Worker and opt in to Worker Versioning.
+To use [Worker Versioning](/worker-versioning), you need to pass a Build ID to your Go Worker and opt in to Worker Versioning.
 
 ### Assign a Build ID to your Worker and opt in to Worker Versioning
 
@@ -215,7 +215,7 @@ When configured to run on a separate Task Queue, they will default to using the
 
 If you want to override this behavior, you can specify your intent via the `VersioningIntent` field on the appropriate options struct.
 
-{/* For more information refer to the [conceptual documentation](/workers#worker-versioning). */}
+{/* For more information refer to the [conceptual documentation](/worker-versioning). */}
 
 For example, if you want an Activity to use the latest assignment rules rather than inheriting from its parent:
 
@@ -244,7 +244,7 @@ err := workflow.NewContinueAsNewError(ctx, "WorkflowName")
 
 :::caution
 
-This section is for a previous Worker Versioning API that is deprecated and will go away at some point. Please redirect your attention to [Worker Versioning](/workers#worker-versioning).
+This section is for a previous Worker Versioning API that is deprecated and will go away at some point. Please redirect your attention to [Worker Versioning](/worker-versioning).
 
 :::
 

docs/develop/java/core-application.mdx

@@ -327,7 +327,7 @@ A single argument is limited to a maximum size of 2 MB.
 And the total size of a gRPC message, which includes all the arguments, is limited to a maximum of 4 MB.
 
 Also, keep in mind that all Payload data is recorded in the [Workflow Execution Event History](/workflows#event-history) and large Event Histories can affect Worker performance.
-This is because the entire Event History could be transferred to a Worker Process with a [Workflow Task](/workers#workflow-task).
+This is because the entire Event History could be transferred to a Worker Process with a [Workflow Task](/tasks#workflow-task).
 
 {/* TODO link to gRPC limit section when available */}
 
@@ -478,7 +478,7 @@ Systems such as Prometheus may ignore metrics with tags using unsupported charac
 
 Calls to spawn [Activity Executions](/activities#activity-execution) are written within a [Workflow Definition](/workflows#workflow-definition).
 The call to spawn an Activity Execution generates the [ScheduleActivityTask](/references/commands#scheduleactivitytask) Command.
-This results in the set of three [Activity Task](/workers#activity-task) related Events ([ActivityTaskScheduled](/references/events#activitytaskscheduled), [ActivityTaskStarted](/references/events#activitytaskstarted), and ActivityTask[Closed])in your Workflow Execution Event History.
+This results in the set of three [Activity Task](/tasks#activity-task) related Events ([ActivityTaskScheduled](/references/events#activitytaskscheduled), [ActivityTaskStarted](/references/events#activitytaskstarted), and ActivityTask[Closed])in your Workflow Execution Event History.
 
 A single instance of the Activities implementation is shared across multiple simultaneous Activity invocations.
 Activity implementation code should be _idempotent_.
@@ -930,7 +930,7 @@ Note that if you define options per-Activity Type options with `WorkflowImplemen
                       .build();
   ```
 
-See [Task Queue](/workers#task-queue)
+See [Task Queue](/task-queue)
 
 #### RetryOptions
 
@@ -1064,7 +1064,7 @@ When the download is complete, the download service potentially can complete the
 The [Worker Process](/workers#worker-process) is where Workflow Functions and Activity Functions are executed.
 
 - Each [Worker Entity](/workers#worker-entity) in the Worker Process must register the exact Workflow Types and Activity Types it may execute.
-- Each Worker Entity must also associate itself with exactly one [Task Queue](/workers#task-queue).
+- Each Worker Entity must also associate itself with exactly one [Task Queue](/task-queue).
 - Each Worker Entity polling the same Task Queue must be registered with the same Workflow Types and Activity Types.
 
 A [Worker Entity](/workers#worker-entity) is the component within a Worker Process that listens to a specific Task Queue.