Temporal Service: Encyclopedia - Activities & Workers

docs/encyclopedia/activities.mdx

@@ -28,7 +28,7 @@ Workflow code orchestrates the execution of Activities, persisting the results.
 If an Activity Function Execution fails, any future execution starts from initial state (except [Heartbeats](#activity-heartbeat)).
 
 Activity Functions are executed by Worker Processes.
-When the Activity Function returns, the Worker sends the results back to the Temporal Cluster as part of the [ActivityTaskCompleted](/references/events#activitytaskcompleted) Event.
+When the Activity Function returns, the Worker sends the results back to the Temporal Service as part of the [ActivityTaskCompleted](/references/events#activitytaskcompleted) Event.
 The Event is added to the Workflow Execution's Event History.
 For other Activity-related Events, see [Activity Events](/workflows#activity-events).
 
@@ -105,7 +105,7 @@ Return values are also captured in the Event History for the calling Workflow Ex
 Activity Definitions must contain the following parameters:
 
 - Context: an optional parameter that provides Activity context within multiple APIs.
-- Heartbeat: a notification from the Worker to the Temporal Cluster that the Activity Execution is progressing. Cancelations are allowed only if the Activity Definition permits Heartbeating.
+- Heartbeat: a notification from the Worker to the Temporal Service that the Activity Execution is progressing. Cancelations are allowed only if the Activity Definition permits Heartbeating.
 - Timeouts: intervals that control the execution and retrying of Activity Task Executions.
 
 Other parameters, such as [Retry Policies](/retry-policies) and return values, can be seen in the implementation guides, listed in the next section.
@@ -210,7 +210,7 @@ In other words, it's a limit for how long an Activity Task can be enqueued.
 - [How to set a Schedule-To-Start Timeout using the TypeScript SDK](/dev-guide/typescript/features#activity-timeouts)
 
 The moment that the Task is picked by the Worker from the Task Queue is considered to be the start of the Activity Task for the purposes of the Schedule-To-Start Timeout and associated metrics.
-This definition of "Start" avoids issues that a clock difference between the Temporal Cluster and a Worker might create.
+This definition of "Start" avoids issues that a clock difference between the Temporal Service and a Worker might create.
 
 <div className="tdiw">
   <div className="tditw">
@@ -320,7 +320,7 @@ If the first Activity Task Execution returns an error the first time, then the f
 If this timeout is reached, the following actions occur:
 
 - An [ActivityTaskTimedOut](/references/events#activitytasktimedout) Event is written to the Workflow Execution's mutable state.
-- If a Retry Policy dictates a retry, the Temporal Cluster schedules another Activity Task.
+- If a Retry Policy dictates a retry, the Temporal Service schedules another Activity Task.
   - The attempt count increments by 1 in the Workflow Execution's mutable state.
   - The Start-To-Close Timeout timer is reset.
 
@@ -378,8 +378,8 @@ Therefore, the Temporal Server relies on the Start-To-Close Timeout to force Act
 
 ### What is an Activity Heartbeat? {#activity-heartbeat}
 
-An Activity Heartbeat is a ping from the Worker that is executing the Activity to the Temporal Cluster.
-Each ping informs the Temporal Cluster that the Activity Execution is making progress and the Worker has not crashed.
+An Activity Heartbeat is a ping from the Worker that is executing the Activity to the Temporal Service.
+Each ping informs the Temporal Service that the Activity Execution is making progress and the Worker has not crashed.
 
 - [How to Heartbeat an Activity using the Go SDK](/dev-guide/go/features#activity-heartbeats)
 - [How to Heartbeat an Activity using the Java SDK](/dev-guide/java/features#activity-heartbeats)
@@ -394,7 +394,7 @@ Custom progress information can be included in the Heartbeat which can then be u
 
 An Activity Heartbeat can be recorded as often as needed (e.g. once a minute or every loop iteration).
 It is often a good practice to Heartbeat on anything but the shortest Activity Function Execution.
-Temporal SDKs control the rate at which Heartbeats are sent to the Cluster.
+Temporal SDKs control the rate at which Heartbeats are sent to the Temporal Service.
 
 Heartbeating is not required from [Local Activities](#local-activity), and does nothing.
 
@@ -404,12 +404,12 @@ That way if a Worker fails it can be handled in a timely manner.
 A Heartbeat can include an application layer payload that can be used to _save_ Activity Execution progress.
 If an [Activity Task Execution](/workers#activity-task-execution) times out due to a missed Heartbeat, the next Activity Task can access and continue with that payload.
 
-Activity Cancellations are delivered to Activities from the Cluster when they Heartbeat. Activities that don't Heartbeat can't receive a Cancellation.
+Activity Cancellations are delivered to Activities from the Temporal Service when they Heartbeat. Activities that don't Heartbeat can't receive a Cancellation.
 Heartbeat throttling may lead to Cancellation getting delivered later than expected.
 
 #### Throttling
 
-Heartbeats may not always be sent to the Cluster—they may be throttled by the Worker.
+Heartbeats may not always be sent to the Temporal Service—they may be throttled by the Worker.
 The throttle interval is the smaller of the following:
 
 - If `heartbeatTimeout` is provided, `heartbeatTimeout * 0.8`; otherwise, `defaultHeartbeatThrottleInterval`
@@ -546,7 +546,7 @@ A Local Activity is an [Activity Execution](#activity-execution) that executes i
 Some Activity Executions are very short-living and do not need the queuing semantic, flow control, rate limiting, and routing capabilities.
 For this case, Temporal supports the Local Activity feature.
 
-The main benefit of Local Activities is that they use less Temporal Cluster resources (for example, fewer History events) and have much lower latency overhead (because no need to roundtrip to the Cluster) compared to normal Activity Executions.
+The main benefit of Local Activities is that they use less Temporal Service resources (for example, fewer History events) and have much lower latency overhead (because no need to roundtrip to the Temporal Service) compared to normal Activity Executions.
 However, Local Activities are subject to shorter durations and a lack of rate limiting.
 
 Consider using Local Activities for functions that are the following:
@@ -556,14 +556,14 @@ Consider using Local Activities for functions that are the following:
 - do not require routing to a specific Worker or Worker pool.
 - no longer than a few seconds, inclusive of retries.
 
-If it takes longer than 80% of the Workflow Task Timeout (which is 10 seconds by default), the Worker will ask the Cluster to create a new Workflow Task to extend the "lease" for processing the Local Activity.
+If it takes longer than 80% of the Workflow Task Timeout (which is 10 seconds by default), the Worker will ask the Temporal Service to create a new Workflow Task to extend the "lease" for processing the Local Activity.
 The Worker will continue doing so until the Local Activity has completed.
 This is called Workflow Task Heartbeating.
 The drawbacks of long-running Local Activities are:
 
 - Each new Workflow Task results in 3 more Events in History.
 - The Workflow won't get notified of new events like Signals and completions until the next Workflow Task Heartbeat.
-- New Commands created by the Workflow concurrently with the Local Activity will not be sent to the Cluster until either the Local Activity completes or the next Workflow Task Heartbeat.
+- New Commands created by the Workflow concurrently with the Local Activity will not be sent to the Temporal Service until either the Local Activity completes or the next Workflow Task Heartbeat.
 
 Using a Local Activity without understanding its limitations can cause various production issues.
 **We recommend using regular Activities unless your use case requires very high throughput and large Activity fan outs of very short-lived Activities.**

docs/encyclopedia/workers.mdx

@@ -112,7 +112,7 @@ Here are some approaches:
   </div>
 </div>
 
-A Worker Process is responsible for polling a [Task Queue](#task-queue), dequeueing a [Task](#task), executing your code in response to a Task, and responding to the [Temporal Cluster](/clusters) with the results.
+A Worker Process is responsible for polling a [Task Queue](#task-queue), dequeueing a [Task](#task), executing your code in response to a Task, and responding to the [Temporal Service](/clusters) with the results.
 
 More formally, a Worker Process is any process that implements the Task Queue Protocol and the Task Execution Protocol.
 
@@ -121,16 +121,16 @@ More formally, a Worker Process is any process that implements the Task Queue Pr
 - A Worker Process is an Activity Worker Process if the process implements the Activity Task Queue Protocol and executes the Activity Task Processing Protocol to make progress on an Activity Execution.
   An Activity Worker Process can listen on an arbitrary number of Activity Task Queues and can execute an arbitrary number of Activity Tasks.
 
-**Worker Processes are external to a Temporal Cluster.**
+**Worker Processes are external to a Temporal Service.**
 Temporal Application developers are responsible for developing [Worker Programs](#worker-program) and operating Worker Processes.
-Said another way, the [Temporal Cluster](/clusters) (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](/workflows#state-transition) and providing Tasks to the next available [Worker Entity](#worker-entity).
+Said another way, the [Temporal Service](/clusters) (including the Temporal Cloud) doesn't execute any of your code (Workflow and Activity Definitions) on Temporal Service machines. The Temporal Service is solely responsible for orchestrating [State Transitions](/workflows#state-transition) and providing Tasks to the next available [Worker Entity](#worker-entity).
 
-While data transferred in Event Histories is [secured by mTLS](/self-hosted-guide/security#encryption-in-transit-with-mtls), by default, it is still readable at rest in the Temporal Cluster.
+While data transferred in Event Histories is [secured by mTLS](/self-hosted-guide/security#encryption-in-transit-with-mtls), by default, it is still readable at rest in the Temporal Service.
 
-To solve this, Temporal SDKs offer a [Data Converter API](/dataconversion) that you can use to customize the serialization of data going out of and coming back in to a Worker Entity, with the net effect of guaranteeing that the Temporal Cluster cannot read sensitive business data.
+To solve this, Temporal SDKs offer a [Data Converter API](/dataconversion) that you can use to customize the serialization of data going out of and coming back in to a Worker Entity, with the net effect of guaranteeing that the Temporal Service cannot read sensitive business data.
 
-In many of our tutorials, we show you how to run both a Temporal Cluster and one Worker on the same machine for local development.
-However, a production-grade Temporal Application typically has a _fleet_ of Worker Processes, all running on hosts external to the Temporal Cluster.
+In many of our tutorials, we show you how to run both a Temporal Service and one Worker on the same machine for local development.
+However, a production-grade Temporal Application typically has a _fleet_ of Worker Processes, all running on hosts external to the Temporal Service.
 A Temporal Application can have as many Worker Processes as needed.
 
 A Worker Process can be both a Workflow Worker Process and an Activity Worker Process.
@@ -147,7 +147,7 @@ Worker Processes executing Activity Tasks must have access to any resources need
 - Credentials for infrastructure provisioning.
 - Specialized GPUs for machine learning utilities.
 
-The Temporal Cluster itself has [internal workers](https://temporal.io/blog/workflow-engine-principles/#system-workflows-1910) for system Workflow Executions.
+The Temporal Service itself has [internal workers](https://temporal.io/blog/workflow-engine-principles/#system-workflows-1910) for system Workflow Executions.
 However, these internal workers are not visible to the developer.
 
 ## What is a Workflow Task? {#workflow-task}
@@ -173,15 +173,15 @@ If Heartbeat data is being passed, an Activity Task will also contain the latest
 
 An Activity Task Execution occurs when a [Worker](#worker-entity) uses the context provided from the [Activity Task](#activity-task) and executes the [Activity Definition](/activities#activity-definition) (also known as the Activity Function).
 
-The [ActivityTaskScheduled Event](/references/events#activitytaskscheduled) corresponds to when the Temporal Cluster puts the Activity Task into the Task Queue.
+The [ActivityTaskScheduled Event](/references/events#activitytaskscheduled) corresponds to when the Temporal Service puts the Activity Task into the Task Queue.
 
 The [ActivityTaskStarted Event](/references/events#activitytaskstarted) corresponds to when the Worker picks up the Activity Task from the Task Queue.
 
-Either [ActivityTaskCompleted](/references/events#activitytaskcompleted) or one of the other Closed Activity Task Events corresponds to when the Worker has yielded back to the Temporal Cluster.
+Either [ActivityTaskCompleted](/references/events#activitytaskcompleted) or one of the other Closed Activity Task Events corresponds to when the Worker has yielded back to the Temporal Service.
 
 The API to schedule an Activity Execution provides an "effectively once" experience, even though there may be several Activity Task Executions that take place to successfully complete an Activity.
 
-Once an Activity Task finishes execution, the Worker responds to the Cluster with a specific Event:
+Once an Activity Task finishes execution, the Worker responds to the Temporal Service with a specific Event:
 
 - ActivityTaskCanceled
 - ActivityTaskCompleted
@@ -211,7 +211,7 @@ There are two types of Task Queues, Activity Task Queues and Workflow Task Queue
 Task Queues are very lightweight components.
 Task Queues do not require explicit registration but instead are created on demand when a Workflow Execution or Activity spawns or when a Worker Process subscribes to it.
 When a Task Queue is created, both a Workflow Task Queue and an Activity Task Queue are created under the same name.
-There is no limit to the number of Task Queues a Temporal Application can use or a Temporal Cluster can maintain.
+There is no limit to the number of Task Queues a Temporal Application can use or a Temporal Service can maintain.
 
 Workers poll for Tasks in Task Queues via synchronous RPC.
 This implementation offers several benefits:
@@ -305,7 +305,7 @@ A Sticky Execution occurs after a Worker Entity completes the first Workflow Tas
 
 The Worker Entity caches the Workflow in memory and begins polling the dedicated Task Queue for Workflow Tasks that contain updates, rather than the entire Event History.
 
-If the Worker Entity does not pick up a Workflow Task from the dedicated Task Queue in an appropriate amount of time, the Cluster will resume Scheduling Workflow Tasks on the original Task Queue.
+If the Worker Entity does not pick up a Workflow Task from the dedicated Task Queue in an appropriate amount of time, the Temporal Service will resume Scheduling Workflow Tasks on the original Task Queue.
 Another Worker Entity can then resume the Workflow Execution, and can set up its own Sticky Execution for future Workflow Tasks.
 
 - [How to set a `StickyScheduleToStartTimeout` on a Worker Entity in Go](/dev-guide/go/foundations#stickyscheduletostarttimeout)
@@ -410,7 +410,7 @@ It also includes features like concurrent session limitations and Worker failure
 
 :::caution
 
-Worker Versioning is currently in Pre-release, and backwards-incompatible changes are coming to the Worker Versioning APIs. For now, you need to provide dynamic configuration parameters to your Cluster to enable Worker Versioning:
+Worker Versioning is currently in Pre-release, and backwards-incompatible changes are coming to the Worker Versioning APIs. For now, you need to provide dynamic configuration parameters to your Temporal Service to enable Worker Versioning:
 
 ```
 temporal server start-dev \