Merge branch 'main' into dependabot/github_actions/actions/setup-node-7.0.0

Author: Duncanma

MARKDOWN_PIPELINE.md

@@ -109,6 +109,7 @@ Each component maps to a strategy in `COMPONENT_REGISTRY` (in `scripts/mdx-to-md
 | `SdkTabs` / `SdkTabs.<Lang>` | `sdk-tabs` | Same, with language labels (`DotNet` → **.NET**) |
 | `CodeSnippet` | `code-snippet` | Fenced code block using the `language` prop |
 | `CaptionedImage`, `EnlargeImage`, `Components.CaptionedImage` | `captioned-image` | `![alt or caption or title](src)` |
+| YouTube/`<iframe>` embeds (often in a styled `<div>`) | strip | Removed; keep a markdown Watch link in surrounding tip/prose for LLMs |
 | `PhotoCarousel` | `photo-carousel` | One `![caption](url)` per entry in the `images`/`captions` arrays |
 | `CallToAction` | `call-to-action` | `- [h3 title](href): p description` |
 | `ReleaseNoteHeader` | `release-note-header` | `> **Public Preview** — Go, Java…` availability note + body blockquote. The self-closing form (`<ReleaseNoteHeader … />`) emits just the note and leaves the page body intact. |

docs/cloud/high-availability/architecture-patterns.mdx

@@ -189,7 +189,7 @@ These patterns work across two cloud regions, which could be in the same cloud p
 | Pattern | Where Workers run | Best for and benefits | Major tradeoffs |
 | --- | --- | --- | --- |
 | **[Active/Passive](#active-cold)** | One region at a time | Easy initial deployment; acts like a single region with no special setup | Failing over Workers is your responsibility; highest recovery time of the three |
-| **[Active/Hot-Passive](#active-hot)** | Both regions; secondary on warm standby | Low RTO with strict single-region behavior; fast Worker failover that is guaranteed to act like a single region | More configuration and the cost of a full standby fleet |
+| **[Active/Hot-Passive](#active-hot)** | Both regions; secondary on warm standby | Low RTO with all task processing in the active region; fast Worker failover with no cold start | More configuration and the cost of a full standby fleet |
 | **[Active/Active](#active-active)** | All regions, all processing Workflows | Low RTO with Workers active in every region; fast failover that uses fleet capacity instead of a standby fleet | Cross-region requests add Workflow latency; external systems need a cross-region consistency story |
 
 ## Active/Passive {/* #active-cold */}
@@ -299,7 +299,7 @@ Keep these in mind when setting up Active/Passive:
 - **Failing over the Workers is the operator's responsibility.** The Namespace fails over automatically, but bringing up the Workers in the secondary region is up to you. Plan for these sub-considerations:
    - **How do you detect an outage and decide to fail over?** Define the failover conditions and the signals (alerts, health checks) that trigger them. Because Workflows make no progress until you detect the outage and respond, detection is on the critical path of your recovery time. To monitor for an outage and a failover, see [Detect a failover or an outage](/cloud/high-availability/monitoring#detect-failover-or-outage).
    - **How do you scale up the Workers?** Bring up the secondary-region fleet, ideally with tested automation, and scale down the primary region's fleet so Workers run in only one region at a time.
-   - **Do you need to enforce single-region processing?** This pattern relies on the operator to keep Workers in one region. To have Temporal enforce single-region processing instead, use the [Active/Hot-Passive](#active-hot) pattern.
+   - **Do you need to enforce single-region task processing?** This pattern relies on the operator to keep Workers in one region. To have Temporal enforce that Workflow and Activity Tasks are processed only in the active region, use the [Active/Hot-Passive](#active-hot) pattern.
 
 ```mermaid
 flowchart LR
@@ -444,7 +444,7 @@ Here's how each component behaves during normal operation and after a failover:
 | --- | --- | --- |
 | **Workers** | Run in both regions. The primary region's Workers are active and process all Workflows; the secondary region's Workers stay connected and warm on standby, doing no work. Forwarding is disabled for Worker polls, so the standby fleet adds no cross-region overhead. | The secondary region's standby Workers — already connected and warm — begin processing immediately. No cold start and no DNS wait. |
 | **Namespace** | Active replica in the primary region; passive replica in the secondary region, continuously receiving replicated Workflow state. | The Namespace and Workers fail over together, automatically: Temporal Cloud promotes the secondary replica to active. |
-| **Workflow starters and Clients** | Run in both regions alongside the Workers. | No changes needed — already running in both regions. |
+| **Workflow starters and Clients** | Run in both regions alongside the Workers. Disabling forwarding does not apply to them: their requests, such as Start Workflow, Signal, and Query, are still forwarded from the secondary region to the active region and succeed. | No changes needed — already running in both regions. |
 | **Codec Servers and proxies** | Run in both regions continuously, not just after a failover. | No changes needed — already running in the secondary region. |
 | **Databases and queues** | Workers in each region typically read and write only their local, active copy. | Promote the secondary region's copy to active, if needed, so the now-active Workers can read and write it. |
 
@@ -459,7 +459,7 @@ Active/Hot-Passive trades steady-state cost for a faster, more predictable failo
 - **Lowest recovery time, tied with Active/Active.**
    - The secondary-region Workers are already connected and warm, so failover involves no cold start. Because the standby fleet is already sized for full load, it also needs no scale-up.
 - **Low latency during normal operation.**
-   - Tasks are processed only in the active region, with no cross-region forwarding.
+   - Workflow and Activity Tasks are processed only in the active region, with no cross-region forwarding of Worker polls. Client requests that originate in the secondary region are still forwarded, and pay the cross-region hop.
 
 ### Tradeoffs {/* #active-hot-tradeoffs */}
 
@@ -473,6 +473,7 @@ Keep this in mind when setting up Active/Hot-Passive:
 
 - **Use Regional or VPC Endpoints and disable forwarding.**
    - Connect each Worker fleet through its region's [Regional Endpoint](/cloud/high-availability/ha-connectivity#regional-endpoint) (or VPC Endpoint) and [disable forwarding](/cloud/high-availability/enable#change-forwarding-behavior) for Worker polls. Using the Namespace Endpoint by mistake routes the standby Workers to the active region and defeats the pattern.
+   - **Disabling forwarding applies to Worker polls only.** Client requests, such as Start Workflow, Signal, Query, Cancel, and Terminate, are always forwarded to the active region. A Workflow starter in the secondary region keeps working, and the Workflows it starts are processed by the active region's Workers. For the full list of APIs that keep forwarding, see [Client requests are forwarded regardless of this setting](/cloud/high-availability/enable#client-requests-still-forwarded).
 
 ```mermaid
 flowchart LR

docs/cloud/high-availability/enable.mdx

@@ -129,23 +129,37 @@ You will receive an email alert once your Namespace is ready for use.
 
 ## Change the forwarding behavior {/* #change-forwarding-behavior */}
 
-Requests that reach the passive replica can be [forwarded](/cloud/high-availability/#request-forwarding) to the active region, and responses sent back to the Worker or Client. The `disablePassivePollerForwarding` Namespace setting controls this behavior for Worker poll traffic.
+Requests that reach the passive replica can be [forwarded](/cloud/high-availability/#request-forwarding) to the active region, and responses sent back to the Worker or Client. The `disablePassivePollerForwarding` Namespace setting controls this behavior for Worker poll traffic only.
 
 With `disablePassivePollerForwarding` enabled, Worker polls that reach a passive replica are not forwarded, and these Workers do not execute Workflows or Activities. Workers connected to such a passive replica receive a `NamespaceNotActive` error on poll requests. These Workers stay connected and will start executing Workflows and Activities if the replica becomes active.
 
-Client APIs (Start, Signal, Cancel, Terminate, Query, and the equivalent Activity APIs) are forwarded to the active region regardless of this setting, with responses sent back to the Client.
-
 Same-region replicas are not affected by this setting.
 
 To deploy Worker fleets in both regions that stay on standby in the passive region until failover, see [Active/Hot-Passive](/cloud/high-availability/architecture-patterns#active-hot).
 
+Set `disablePassivePollerForwarding` through the [Cloud Ops API](/ops), the [cloud-api SDK](https://github.com/temporalio/cloud-sdk-go), or the [`temporal cloud` CLI extension](/cli/cloud), using one of the recipes in this section.
+
 :::info
 
 To see which endpoints route to which replica, see [How requests reach the replica](/cloud/high-availability/ha-connectivity#how-requests-reach-the-replica).
 
 :::
 
-`disablePassivePollerForwarding` can be set through the [Cloud Ops API](/ops), the [cloud-api SDK](https://github.com/temporalio/cloud-sdk-go), or the [`temporal cloud` CLI extension](/cli/cloud). Use one of the recipes below.
+### Client requests are forwarded regardless of this setting {/* #client-requests-still-forwarded */}
+
+`disablePassivePollerForwarding` stops Worker polls. It does not stop Client requests. The following APIs are forwarded from the passive replica to the active region whether or not the setting is enabled, with responses returned to the Client:
+
+| API group | Forwarded operations |
+| --- | --- |
+| Workflow | Start Workflow, Signal-with-Start, Signal, Cancel, Terminate, Delete, Query |
+| [Standalone Activity](/standalone-activity) | Start, Cancel, Terminate, Delete, Pause, Unpause, Reset, Update Activity Options |
+| [Standalone Nexus Operation](/standalone-nexus-operation) | Start, Cancel, Terminate, Delete |
+
+For the current list, see [`selectedAPIsForwardingRedirectionPolicyWhitelistedAPIs`](https://github.com/temporalio/temporal/blob/main/common/rpc/interceptor/dc_redirection_policy.go#L59-L71) in the Temporal Server source.
+
+A Client that reaches the passive replica, for example through the passive region's Regional Endpoint, keeps working while the setting is enabled: it can start Workflows, send Signals, and run Queries successfully. Workers in the active region process the resulting Workflow and Activity Tasks, because the passive region's Workers receive none.
+
+Plan for this if you disable forwarding to keep a region's traffic out of the active region. The setting stops that region's Workers from processing tasks. It does not stop Workflow starters, Signal senders, or other Clients in that region from reaching the Namespace.
 
 ### Set the forwarding behavior with the `temporal cloud` CLI {/* #set-forwarding-cli */}
 

docs/cloud/high-availability/ha-connectivity.mdx

@@ -88,6 +88,7 @@ A request can reach the passive replica in three ways:
   If #1 completes before #2, a Worker that was connected to the former active before the failover will stay connected to it even after it becomes the replica. The Worker will change to point at the new active when the DNS changes propagate and the Client re-resolves DNS (typically 30 seconds, though up to 5 minutes, bounded by Temporal Cloud's maximum connection lifetime).
 
 By default, Temporal Cloud transparently forwards any request that reaches the passive replica to the active region, and the response back.
+You can turn forwarding off for Worker polls, but Client requests such as Start Workflow, Signal, and Query are always forwarded.
 
 To learn what forwarding does, see [Request forwarding](/cloud/high-availability/#request-forwarding).
 

docs/cloud/high-availability/index.mdx

@@ -101,9 +101,13 @@ When a request reaches the passive replica — for example, through the passive
 
 Forwarding adds a cross-region hop, so requests that travel through the passive replica complete with higher average latency than requests that reach the active replica directly.
 
+You can turn off forwarding for Worker poll requests, which keeps the passive region's Workers from processing tasks. Client requests such as Start Workflow, Signal, Query, Cancel, and Terminate are always forwarded, so a Client that reaches the passive replica keeps working either way.
+
 To route Workers to the passive region's replica, see [How requests reach the replica](/cloud/high-availability/ha-connectivity#how-requests-reach-the-replica).
 
-To disable passive region replica forwarding, see [Change the forwarding behavior](/cloud/high-availability/enable#change-forwarding-behavior).
+To stop forwarding Worker polls that reach the passive replica, see [Change the forwarding behavior](/cloud/high-availability/enable#change-forwarding-behavior).
+
+To see which Client requests keep forwarding either way, see [Client requests are forwarded regardless of this setting](/cloud/high-availability/enable#client-requests-still-forwarded).
 
 To run Worker fleets in both regions that rely on this forwarding, see [Active/Active](/cloud/high-availability/architecture-patterns#active-active).
 

docs/cloud/metrics/openmetrics/api-reference.mdx

@@ -78,6 +78,7 @@ The list of metrics and their labels are available via the [List Descriptors](/c
 ### Labels
 
 A label is a key-value attribute associated with a metric data point. Labels can be used to filter or aggregate metrics.
+Temporal SDKs and the Temporal Service call this same concept a [tag](/glossary#tag); it's called a label once scraped in OpenMetrics format.
 
 Common labels include:
 

docs/design-patterns/retry-metrics.mdx

@@ -287,9 +287,9 @@ export async function monitoredRetryWorkflow(endpoint: string): Promise<string>
 </TabItem>
 </Tabs>
 
-### Add dimension labels to the metric
+### Add dimension tags to the metric
 
-Add labels (tags) to the metric to identify which Activity type, endpoint, or Workflow is producing the high attempt counts.
+Add tags to the metric to identify which Activity type, endpoint, or Workflow is producing the high attempt counts.
 This makes the metric actionable in dashboards and alerts.
 
 <Tabs groupId="language" queryString>
@@ -356,7 +356,7 @@ if (ctx.info.attempt > ALERT_THRESHOLD) {
 
 - **Choose a threshold above normal transient noise.** If your downstream system occasionally has 1–2 retry attempts under normal conditions, set the threshold at 5 or 10 so the metric only fires for genuinely sustained failures.
 - **Emit on every attempt above the threshold, not only once.** Incrementing the counter on each high-attempt invocation allows alerting systems to detect both the onset and the duration of a problem by watching the counter rate.
-- **Use the SDK metrics scope, not a third-party library.** The SDK scope integrates with your Worker's existing metrics pipeline and adds default labels such as namespace and task queue automatically.
+- **Use the SDK metrics scope, not a third-party library.** The SDK scope integrates with your Worker's existing metrics pipeline and adds default tags such as namespace and task queue automatically.
 - **Set up rate-based alerts, not count-based.** A count alert requires resetting or remembering the baseline. A rate alert (e.g., "more than 3 increments per minute") fires when the problem is active and clears when it resolves.
 - **Combine with Fast/Slow Retries.** Emit the metric in the slow-phase Activity of a [Fast/Slow Retries](/design-patterns/fast-slow-retries) pattern to alert when the Workflow has been in the slow phase long enough to be a concern.
 

docs/develop/go/workflows/selectors.mdx

@@ -101,7 +101,7 @@ If multiple items are available, the order of matching is not defined.
 
 An important use case of futures is setting up a race between a timer and a pending activity, effectively adding a "soft" timeout that doesn't result in any errors or retries of that activity.
 
-For example, [the Timer sample](https://github.com/temporalio/samples-go/blob/master/timer) shows how you can write a long running order processing operation where:
+For example, [the Timer sample](https://github.com/temporalio/samples-go/tree/main/timer) shows how you can write a long running order processing operation where:
 
 - if processing takes too long, we send out a notification email to user about the delay, but we won't cancel the operation
 - if the operation finishes before the timer fires, then we want to cancel the timer.

docs/develop/java/best-practices/data-handling/data-encryption.mdx

@@ -163,4 +163,4 @@ You create, operate, and manage access to your Codec Server in your own environm
 The Temporal CLI and the Web UI in turn provide built-in hooks to call the Codec Server to decode encrypted payloads on demand.
 Refer to the [Codec Server](/production-deployment/data-encryption) documentation for information on how to design and deploy a Codec Server.
 
-For reference, see the [Codec server](https://github.com/temporalio/sdk-java/tree/master/temporal-remote-data-encoder) sample.
+For reference, see the [Codec server](https://github.com/temporalio/sdk-java/tree/main/temporal-remote-data-encoder) sample.

docs/develop/java/client/temporal-client.mdx

@@ -669,7 +669,7 @@ A Workflow Execution can be started either synchronously or asynchronously.
 
 - Asynchronous start initiates a Workflow Execution and immediately returns to the caller. This is the most common way
   to start Workflows in production code. The
-  [`WorkflowClient`](https://github.com/temporalio/sdk-java/blob/master/temporal-sdk/src/main/java/io/temporal/client/WorkflowClient.java)
+  [`WorkflowClient`](https://github.com/temporalio/sdk-java/blob/main/temporal-sdk/src/main/java/io/temporal/client/WorkflowClient.java)
   provides some static methods, such as `start`, `execute`, `signalWithStart` etc., that help with starting your
   Workflows asynchronously.