Merge branch 'main' into ha-connectivity-endpoints

Author: brianmacdonald-temporal

docs/best-practices/cost-optimization.mdx

@@ -62,7 +62,7 @@ See [Spooky Stories: Chilling Temporal Anti-Patterns](https://temporal.io/blog/s
 ### Large payloads in Workflow History
 
 Passing multi-megabyte payloads through Workflows when external storage (S3, blob storage) is more appropriate.
-Use [compression](/troubleshooting/blob-size-limit-error#why-does-this-error-occur) or the [claim check pattern](https://dataengineering.wiki/Concepts/Software+Engineering/Claim+Check+Pattern) for large data.
+Use [compression](/troubleshooting/blob-size-limit-error#payload-size-limit) or the [claim check pattern](https://dataengineering.wiki/Concepts/Software+Engineering/Claim+Check+Pattern) for large data.
 
 ### Over-optimization at the expense of observability
 

docs/cloud/capacity-modes.mdx

@@ -133,12 +133,6 @@ This means that your default limit would be 800 APS.
 
 ## Provisioned Capacity {#provisioned-capacity}
 
-:::tip Support, stability, and dependency info
-
-Provisioned Capacity is currently in [Public Preview](/evaluate/development-production-features/release-stages#public-preview).
-
-:::
-
 Provisioned Capacity provides an alternative to On-Demand Capacity by allowing you to control the limits on your Namespace based on your specific need.
 
 |               | Actions Per Second | Requests Per Second | Operations Per Second|

docs/cloud/worker-health.mdx

@@ -39,6 +39,12 @@ This page is a guide to monitoring a Temporal Worker fleet and covers the follow
 - [How to detect misconfigured Workers](#detect-misconfigured-workers)
 - [How to configure Sticky cache](#configure-sticky-cache)
 
+:::tip
+
+You can also inspect Workers and the Workers assigned to a Task Queue directly in the Temporal UI. See [Visualize Workers in the UI](/develop/worker-performance#visualize-workers).
+
+:::
+
 ## Minimal Observations {#minimal-observations}
 
 These alerts should be configured and understood first to gain intelligence into your application health and behaviors.
@@ -450,6 +456,14 @@ Set the `WorkerHeartbeatInterval` property on [`TemporalRuntimeOptions`](https:/
 Set it to `null` to disable heartbeating.
 
 </SdkTabs.DotNet>
+<SdkTabs.Java>
+
+_Available since Java SDK v1.35.0_
+
+Set the heartbeat interval on [`WorkflowClientOptions.Builder`](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/client/WorkflowClientOptions.Builder.html) with `setWorkerHeartbeatInterval(Duration)`.
+Set it to a negative `Duration` to disable heartbeating.
+
+</SdkTabs.Java>
 <SdkTabs.Ruby>
 
 _Available since Ruby SDK v1.1.0_

docs/develop/dotnet/activities/standalone-activities.mdx

@@ -22,9 +22,7 @@ description: Execute Activities independently without a Workflow using the Tempo
 :::tip SUPPORT, STABILITY, and DEPENDENCY INFO
 
 Temporal .NET SDK support for [Standalone Activities](/standalone-activity) is at
-[Pre-release](/evaluate/development-production-features/release-stages#pre-release).
-
-All APIs are experimental and may be subject to backwards-incompatible changes.
+[Public Preview](/evaluate/development-production-features/release-stages#public-preview).
 
 :::
 
@@ -63,47 +61,26 @@ Prerequisites:
 
 - **Temporal .NET SDK** (v1.12.0 or higher). See the [.NET Quickstart](https://docs.temporal.io/develop/dotnet/set-up-your-local-dotnet) for install instructions.
 
-- **Temporal CLI** (Pre-release version with Standalone Activity support)
-
-  Download for your platform:
+- **Temporal CLI** v1.7.0 or higher
 
-  ```bash title="macOS (Apple Silicon)"
-  curl -L https://github.com/temporalio/cli/releases/download/v1.6.2-standalone-activity/temporal_cli_1.6.2-standalone-activity_darwin_arm64.tar.gz | tar xz
-  ```
+  Install with Homebrew:
 
-  ```bash title="macOS (Intel)"
-  curl -L https://github.com/temporalio/cli/releases/download/v1.6.2-standalone-activity/temporal_cli_1.6.2-standalone-activity_darwin_amd64.tar.gz | tar xz
-  ```
-
-  ```bash title="Linux (arm64)"
-  curl -L https://github.com/temporalio/cli/releases/download/v1.6.2-standalone-activity/temporal_cli_1.6.2-standalone-activity_linux_arm64.tar.gz | tar xz
+  ```bash
+  brew install temporal
   ```
 
-  ```bash title="Linux (amd64)"
-  curl -L https://github.com/temporalio/cli/releases/download/v1.6.2-standalone-activity/temporal_cli_1.6.2-standalone-activity_linux_amd64.tar.gz | tar xz
-  ```
+  Or see the [Temporal CLI install guide](/cli#install) for other platforms.
 
   Verify the installation:
 
   ```bash
-  ./temporal --version
-  # temporal version 1.6.2-standalone-activity (Server 1.31.0-151.2, UI 2.47.2)
+  temporal --version
   ```
 
-  Move the binary to your PATH or run it from the current directory as `./temporal`.
-
-  :::warning
-
-  If you see `Standalone activity is disabled` when running commands, you are using the standard
-  Temporal CLI instead of the pre-release version above. The standard `brew install temporal` or
-  `brew upgrade temporal` does not include Standalone Activity support during Pre-release.
-
-  :::
-
 Start the Temporal development server:
 
 ```bash
-./temporal server start-dev
+temporal server start-dev
 ```
 
 This command automatically starts the Temporal development server with the Web UI, and creates the `default` Namespace.
@@ -251,7 +228,7 @@ You can pass the Activity as either a lambda expression or a string Activity typ
 // Using a lambda expression (type-safe)
 var result = await client.ExecuteActivityAsync(
     () => MyActivities.ComposeGreetingAsync(new ComposeGreetingInput("Hello", "World")),
-    new("my-activity-id", "my-task-queue")
+    new("standalone-activity-id", "standalone-activity-sample")
     {
         ScheduleToCloseTimeout = TimeSpan.FromSeconds(10),
     });
@@ -260,7 +237,7 @@ var result = await client.ExecuteActivityAsync(
 var result = await client.ExecuteActivityAsync<string>(
     "ComposeGreeting",
     new object?[] { new ComposeGreetingInput("Hello", "World") },
-    new("my-activity-id", "my-task-queue")
+    new("standalone-activity-id", "standalone-activity-sample")
     {
         ScheduleToCloseTimeout = TimeSpan.FromSeconds(10),
     });
@@ -284,7 +261,7 @@ dotnet run --project src/StandaloneActivity execute-activity
 Or use the Temporal CLI:
 
 ```bash
-./temporal activity execute \
+temporal activity execute \
   --type ComposeGreeting \
   --activity-id standalone-activity-id \
   --task-queue standalone-activity-sample \
@@ -331,7 +308,7 @@ dotnet run --project src/StandaloneActivity start-activity
 Or use the Temporal CLI:
 
 ```bash
-./temporal activity start \
+temporal activity start \
   --type ComposeGreeting \
   --activity-id standalone-activity-id \
   --task-queue standalone-activity-sample \
@@ -366,7 +343,7 @@ var result = await handle.GetResultAsync();
 Or use the Temporal CLI to wait for a result by Activity ID:
 
 ```bash
-./temporal activity result --activity-id my-standalone-activity-id
+temporal activity result --activity-id my-standalone-activity-id
 ```
 
 ## List Standalone Activities {#list-activities}
@@ -405,7 +382,7 @@ dotnet run --project src/StandaloneActivity list-activities
 Or use the Temporal CLI:
 
 ```bash
-./temporal activity list
+temporal activity list
 ```
 
 The query parameter accepts the same [List Filter](/list-filter) syntax used for [Workflow
@@ -443,7 +420,7 @@ dotnet run --project src/StandaloneActivity count-activities
 Or use the Temporal CLI:
 
 ```bash
-./temporal activity count
+temporal activity count
 ```
 
 ## Run Standalone Activities with Temporal Cloud {#run-standalone-activities-temporal-cloud}

docs/develop/dotnet/workflows/basics.mdx

@@ -44,11 +44,9 @@ All Workflow Definition parameters must be serializable.
 
 ## Workflow logic requirements {#workflow-logic-requirements}
 
-Workflow logic is constrained by [deterministic execution requirements](/workflow-definition#deterministic-constraints).
-Therefore, each language is limited to the use of certain idiomatic techniques.
-However, each Temporal SDK provides a set of APIs that can be used inside your Workflow to interact with external (to the Workflow) application code.
+Workflow logic is constrained by [deterministic execution requirements](/workflow-definition#deterministic-constraints). Each Temporal SDK provides a set of APIs that can be used inside your Workflow to interact with application code outside the Workflow.
 
-This means there are several things Workflows cannot do such as:
+This means there are several things Workflows shouldn't do such as:
 
 - Perform IO (network, disk, stdio, etc)
 - Access/alter external mutable state
@@ -65,34 +63,28 @@ This is especially true with `Task`s.
 Temporal requires that the deterministic `TaskScheduler.Current` is used, but many .NET async calls will use `TaskScheduler.Default` implicitly (and some analyzers even encourage this).
 Here are some known gotchas to avoid with .NET tasks inside of Workflows:
 
-- Do not use `Task.Run` - this uses the default scheduler and puts work on the thread pool.
-  - Use `Workflow.RunTaskAsync` instead.
-  - Can also use `Task.Factory.StartNew` with current scheduler or instantiate the `Task` and run `Task.Start` on it.
-- Do not use `Task.ConfigureAwait(false)` - this will not use the current context.
-  - If you must use `Task.ConfigureAwait`, use `Task.ConfigureAwait(true)`.
-  - There is no significant performance benefit to `Task.ConfigureAwait` in workflows anyways due to how the scheduler works.
-- Do not use anything that defaults to the default task scheduler.
-- Do not use `Task.Delay`, `Task.Wait`, timeout-based `CancellationTokenSource`, or anything that uses .NET built-in timers.
-  - `Workflow.DelayAsync`, `Workflow.WaitConditionAsync`, or non-timeout-based cancellation token source is suggested.
-- Do not use `Task.WhenAny`.
-  - Use `Workflow.WhenAnyAsync` instead.
+-  Use `Workflow.RunTaskAsync` instead of `Task.Run`. `Task.Run` uses the default scheduler and puts work on the thread pool.
+    - You can also use `Task.Factory.StartNew` with current scheduler or instantiate the `Task` and run `Task.Start` on it.
+- If you need to use `Task.ConfigureAwait`, use `Task.ConfigureAwait(true)`. `Task.ConfigureAwait(false)` won't use the current context.
+  - There is no significant performance benefit to `Task.ConfigureAwait` in workflows because of how the scheduler works.
+- Avoid anything that defaults to the default task scheduler.
+- Use `Workflow.DelayAsync`, `Workflow.WaitConditionAsync`, or non-timeout-based cancellation token sources instead of `Task.Delay`, `Task.Wait`, timeout-based `CancellationTokenSource`, or anything that uses .NET built-in timers.
+- Use `Workflow.WhenAnyAsync` instead of `Task.WhenAny`.
   - Technically this only applies to an enumerable set of tasks with results or more than 2 tasks with results. Other
     uses are safe. See [this issue](https://github.com/dotnet/runtime/issues/87481).
-- Do not use `Task.WhenAll`
-  - Use `Workflow.WhenAllAsync` instead.
+- Use `Workflow.WhenAllAsync` instead of `Task.WhenAll`.
   - Technically `Task.WhenAll` is currently deterministic in .NET and safe, but it is better to use the wrapper to be
     sure.
-- Do not use `CancellationTokenSource.CancelAsync`.
-  - Use `CancellationTokenSource.Cancel` instead.
-- Do not use `System.Threading.Semaphore` or `System.Threading.SemaphoreSlim` or `System.Threading.Mutex`.
-  - Use `Temporalio.Workflows.Semaphore` or `Temporalio.Workflows.Mutex` instead.
+- Use `CancellationTokenSource.Cancel` instead of `CancellationTokenSource.CancelAsync`.
+- Use `Temporalio.Workflows.Semaphore` or `Temporalio.Workflows.Mutex` instead of `System.Threading.Semaphore`, `System.Threading.SemaphoreSlim`, or `System.Threading.Mutex`.
   - _Technically_ `SemaphoreSlim` does work if only the async form of `WaitAsync` is used without no timeouts and
     `Release` is used. But anything else can deadlock the workflow and its use is cumbersome since it must be disposed.
 - Be wary of additional libraries' implicit use of the default scheduler.
   - For example, while there are articles for `Dataflow` about [using a specific scheduler](https://learn.microsoft.com/en-us/dotnet/standard/parallel-programming/how-to-specify-a-task-scheduler-in-a-dataflow-block), there are hidden implicit uses of `TaskScheduler.Default`. For example, see [this bug](https://github.com/dotnet/runtime/issues/83159).
 
 In order to help catch wrong scheduler use, by default the Temporal .NET SDK adds an event source listener for info-level task events.
 While this technically receives events from all uses of tasks in the process, we make sure to ignore anything that is not running in a Workflow in a high performant way (basically one thread local check).
+
 For code that does run in a Workflow and accidentally starts a task in another scheduler, an `InvalidWorkflowOperationException` will be thrown which "pauses" the Workflow (fails the Workflow Task which continually retries until the code is fixed).
 This is unfortunately a runtime-only check, but can help catch mistakes early. If this needs to be turned off for any reason, set `DisableWorkflowTracingEventListener` to `true` in Worker options.
 

docs/develop/dotnet/workflows/cancellation.mdx

@@ -90,15 +90,18 @@ public async Task RunAsync()
 
         // Call cleanup activity. If this throws, it will swallow the original exception which we
         // are ok with here. This could be changed to just log a failure and let the original
-        // cancellation continue. We use a different cancellation token since the default one on
-        // Workflow.CancellationToken is now marked cancelled.
-        using var detachedCancelSource = new CancellationTokenSource();
+        // cancellation continue. 
+        // The default token on Workflow.CancellationToken is now marked
+        // cancelled, so we pass a different one. We use CancellationToken.None here because the
+        // cleanup activity itself doesn't need to be cancellable; if it did (e.g. you want to
+        // cancel cleanup from a timeout or another signal), create a new detached
+        // CancellationTokenSource and pass its Token instead.
         await Workflow.ExecuteActivityAsync(
             (MyActivities a) => a.MyCancellationCleanupActivity(),
             new()
             {
                 ScheduleToCloseTimeout = TimeSpan.FromMinutes(5),
-                CancellationToken = detachedCancelSource.Token;
+                CancellationToken = CancellationToken.None,
             });
 
         // Rethrow the cancellation

docs/develop/dotnet/workflows/versioning.mdx

@@ -31,8 +31,8 @@ import { CaptionedImage } from '@site/src/components';
 
 Since Workflow Executions in Temporal can run for long periods — sometimes months or even years — it's common to need to make changes to a Workflow Definition, even while a particular Workflow Execution is in progress.
 
-The Temporal Platform requires that Workflow code is [deterministic](/workflow-definition#deterministic-constraints).
-If you make a change to your Workflow code that would cause non-deterministic behavior on Replay, you'll need to use one of our Versioning methods to gracefully update your running Workflows.
+The Temporal Platform requires that Workflow code is [deterministic](/workflow-definition#deterministic-constraints). If you make a change to your Workflow code that would cause non-deterministic behavior on Replay, you'll need to use one of our Versioning methods to gracefully update your running Workflows. This only applies to Workflow orchestration logic. Non-deterministic work such as API calls, and database queries should be placed in Activities, which Temporal retries reliably.
+
 With Versioning, you can modify your Workflow Definition so that new executions use the updated code, while existing ones continue running the original version.
 There are two primary Versioning methods that you can use:
 

docs/develop/go/activities/standalone-activities.mdx

@@ -22,9 +22,7 @@ description: Execute Activities independently without a Workflow using the Tempo
 :::tip SUPPORT, STABILITY, and DEPENDENCY INFO
 
 Temporal Go SDK support for [Standalone Activities](/standalone-activity) is at
-[Pre-release](/evaluate/development-production-features/release-stages#pre-release).
-
-All APIs are experimental and may be subject to backwards-incompatible changes.
+[Public Preview](/evaluate/development-production-features/release-stages#public-preview).
 
 :::
 
@@ -62,47 +60,26 @@ Prerequisites:
 
 - **[Temporal Go SDK](https://docs.temporal.io/develop/go/core-application#install-a-temporal-sdk)** (v1.41.0 or higher)
 
-- **Temporal CLI** (Pre-release version with Standalone Activity support)
-
-  Download for your platform:
+- **Temporal CLI** v1.7.0 or higher
 
-  ```bash title="macOS (Apple Silicon)"
-  curl -L https://github.com/temporalio/cli/releases/download/v1.6.2-standalone-activity/temporal_cli_1.6.2-standalone-activity_darwin_arm64.tar.gz | tar xz
-  ```
+  Install with Homebrew:
 
-  ```bash title="macOS (Intel)"
-  curl -L https://github.com/temporalio/cli/releases/download/v1.6.2-standalone-activity/temporal_cli_1.6.2-standalone-activity_darwin_amd64.tar.gz | tar xz
+  ```bash
+  brew install temporal
   ```
 
-  ```bash title="Linux (arm64)"
-  curl -L https://github.com/temporalio/cli/releases/download/v1.6.2-standalone-activity/temporal_cli_1.6.2-standalone-activity_linux_arm64.tar.gz | tar xz
-  ```
-
-  ```bash title="Linux (amd64)"
-  curl -L https://github.com/temporalio/cli/releases/download/v1.6.2-standalone-activity/temporal_cli_1.6.2-standalone-activity_linux_amd64.tar.gz | tar xz
-  ```
+  Or see the [Temporal CLI install guide](/cli#install) for other platforms.
 
   Verify the installation:
 
   ```bash
-  ./temporal --version
-  # temporal version 1.6.2-standalone-activity (Server 1.31.0-151.2, UI 2.47.2)
+  temporal --version
   ```
 
-  Move the binary to your PATH or run it from the current directory as `./temporal`.
-
-  :::warning
-
-  If you see `Standalone activity is disabled` when running commands, you are using the standard
-  Temporal CLI instead of the pre-release version above. The standard `brew install temporal` or
-  `brew upgrade temporal` does not include Standalone Activity support during Pre-release.
-
-  :::
-
 Start the Temporal development server:
 
 ```
-./temporal server start-dev
+temporal server start-dev
 ```
 
 This command automatically starts the Temporal development server with the Web UI, and creates the `default` Namespace.
@@ -319,7 +296,7 @@ go run standalone-activity/helloworld/starter/main.go
 Or use the Temporal CLI to execute a Standalone Activity:
 
 ```bash
-./temporal activity execute \
+temporal activity execute \
   --type Activity \
   --activity-id standalone_activity_helloworld_ActivityID \
   --task-queue standalone-activity-helloworld \
@@ -347,7 +324,7 @@ the failure is returned as an error.
 Or use the Temporal CLI to wait for a result by Activity ID:
 
 ```bash
-./temporal activity result --activity-id my-standalone-activity-id
+temporal activity result --activity-id standalone_activity_helloworld_ActivityID
 ```
 
 ## Get a handle to an existing Standalone Activity {#get-activity-handle}
@@ -359,7 +336,7 @@ Both `ActivityID` and `RunID` are required.
 
 ```go
 handle := c.GetActivityHandle(client.GetActivityHandleOptions{
-	ActivityID: "my-standalone-activity-id",
+	ActivityID: "standalone_activity_helloworld_ActivityID",
 	RunID:      "the-run-id",
 })
 
@@ -399,7 +376,7 @@ for info, err := range resp.Results {
 Or use the Temporal CLI:
 
 ```bash
-./temporal activity list
+temporal activity list
 ```
 
 The `Query` field accepts the same [List Filter](/list-filter) syntax used for Workflow Visibility. For example,
@@ -426,7 +403,7 @@ log.Println("Total activities:", resp.Count)
 Or use the Temporal CLI:
 
 ```bash
-./temporal activity count
+temporal activity count
 ```
 
 ## Run Standalone Activities with Temporal Cloud {#run-standalone-activities-temporal-cloud}