Merge branch 'main' into php-quick-start

Author: jsundai

docs/cloud/nexus/limits.mdx

@@ -39,8 +39,8 @@ Nexus has operational limits for thing like the maximum number of Nexus Endpoint
 
 ### Max Nexus Endpoints
 
-By default, each account is provisioned with a max of 10 Nexus Endpoints.
-You can request further increases beyond the initial 10 Endpoint limit by opening a support ticket.
+By default, each account is provisioned with a max of 100 Nexus Endpoints.
+You can request further increases beyond the initial 100 Endpoint limit by opening a support ticket.
 
 ### Workflow Max Nexus Operations
 

docs/develop/python/python-sdk-sync-vs-async.mdx

@@ -69,7 +69,7 @@ such as `aiohttp` or `httpx`. Otherwise, use a synchronous Activity.
 
 ## Python SDK Worker Execution Architecture
 
-Python workers have following components for executing code:
+Python workers have the following components for executing code:
 
 - Your event loop, which runs Tasks from async Activities **plus the rest of the Temporal Worker, such as communicating with the server**.
 - An executor for executing Activity Tasks from synchronous Activities. A thread pool executor is recommended.

docs/develop/python/set-up.mdx

@@ -210,6 +210,7 @@ Create a Worker file (worker.py):
 import asyncio
 from temporalio.client import Client
 from temporalio.worker import Worker
+from temporalio import workflow
 
 with workflow.unsafe.imports_passed_through():
     from workflows import SayHelloWorkflow

docs/develop/python/temporal-client.mdx

@@ -291,7 +291,7 @@ overrides the option set in the configuration file.
 
 :::
 
-For example, the following TOML configuration file defines a `staing` profile with the necessary connection options to
+For example, the following TOML configuration file defines a `staging` profile with the necessary connection options to
 connect to Temporal Cloud via an API key:
 
 For example, the following TOML configuration file defines a `staging` profile with the necessary connection options to

docs/develop/ruby/temporal-client.mdx

@@ -253,7 +253,7 @@ overrides the option set in the configuration file.
 
 :::
 
-For example, the following TOML configuration file defines a `staing` profile with the necessary connection options to
+For example, the following TOML configuration file defines a `staging` profile with the necessary connection options to
 connect to Temporal Cloud via an API key:
 
 For example, the following TOML configuration file defines a `staging` profile with the necessary connection options to

docs/encyclopedia/nexus-operations.mdx

@@ -161,7 +161,7 @@ Nexus Machinery on both sides handles the cross-namepace communication.
 
 For example, when you execute a Nexus Operation in a caller Workflow the following Namespace gRPC calls are made:
 
-1. **RespondWorkflowTaskCompleted ([ScheduleNexusOperation command](/references/commands#schedulenexusoperation)) is used by the caller Worker to schedule a Nexus Operation, which atomically hands off execution to the caller's Nexus Machinery.
+1. **RespondWorkflowTaskCompleted** ([ScheduleNexusOperation command](/references/commands#schedulenexusoperation)) is used by the caller Worker to schedule a Nexus Operation, which atomically hands off execution to the caller's Nexus Machinery.
 1. **PollNexusTaskQueue** is used by the handler Worker to receive a [Nexus Task](/tasks#nexus-task) to process, for example to start a Nexus Operation.
 1. **RespondNexusTaskCompleted** or **RespondNexusTaskFailed** is used by the handler Worker to return the Nexus Task result.
    When asked to start a Nexus Operation, the Nexus handler decides if the Operation will be synchronous or asynchronous.

docs/encyclopedia/workflow/workflow-overview.mdx

@@ -1,16 +1,18 @@
 ---
 id: workflow-overview
 title: Temporal Workflow
-sidebar_label: Workflow 
-description: This comprehensive guide provides insights into Temporal Workflows, covering Workflow Definitions in various programming languages, deterministic constraints, handling code changes, and ensuring reliability, durability, and scalability in a Temporal Application, with examples and best practices for Workflow Versioning and development.
+sidebar_label: Workflow
+description:
+  This comprehensive guide provides insights into Temporal Workflows, covering Workflow Definitions in various
+  programming languages, deterministic constraints, handling code changes, and ensuring reliability, durability, and
+  scalability in a Temporal Application, with examples and best practices for Workflow Versioning and development.
 slug: /workflows
 toc_max_heading_level: 4
 keywords:
-  - workflow 
+  - workflow
 tags:
   - Concepts
   - Workflows
-
 ---
 
 This guide provides a comprehensive overview of Temporal Workflows and covers the following:
@@ -23,25 +25,29 @@ This guide provides a comprehensive overview of Temporal Workflows and covers th
 
 ## Intro to Workflows
 
-Conceptually, a workflow defines a sequence of steps.
-With Temporal, those steps are defined by writing code, known as a Workflow Definition, and are carried out by running that code, which results in a Workflow Execution.
+Conceptually, a workflow defines a sequence of steps. With Temporal, those steps are defined by writing code, known as a
+Workflow Definition, and are carried out by running that code, which results in a Workflow Execution.
 
-In day-to-day conversations, the term Workflow might refer to Workflow Type, a Workflow Definition, or a Workflow Execution.
+In day-to-day conversations, the term Workflow might refer to Workflow Type, a Workflow Definition, or a Workflow
+Execution.
 
 1. A **Workflow Definition** is the code that defines your Workflow.
-2. The **Workflow Type** is the name that maps to a Workflow Definition.
-   It's an identifier that makes it possible to distinguish one type of Workflow (such as order processing) from another (such as customer onboarding).
-3. A **Workflow Execution** is a running Workflow, which is created by combining a Workflow Definition with a request to execute it.
-   You can execute a Workflow Definition any number of times, potentially providing different input each time (i.e., a Workflow Definition for order processing might process order #123 in one execution and order #567 in another execution).
-   It is the actual instance of the Workflow Definition running in the Temporal Platform.
-
-You'll develop those Workflows by writing code in a general-purpose programming language such as Go, Java, TypeScript, or Python.
-The code you write is the same code that will be executed at runtime, so you can use your favorite tools and libraries to develop Temporal Workflows.
-
-Temporal Workflows are resilient.
-They can run—and keeping running—for years, even if the underlying infrastructure fails.
-If the application itself crashes, Temporal will automatically recreate its pre-failure state so it can continue right where it left off.
-
-Each Workflow Execution progresses through a series of **Commands** and **Events**, which are recorded in an **Event History**.
+2. The **Workflow Type** is the name that maps to a Workflow Definition. It's an identifier that makes it possible to
+   distinguish one type of Workflow (such as order processing) from another (such as customer onboarding).
+3. A **Workflow Execution** is a running Workflow, which is created by combining a Workflow Definition with a request to
+   execute it. You can execute a Workflow Definition any number of times, potentially providing different input each
+   time (i.e., a Workflow Definition for order processing might process order #123 in one execution and order #567 in
+   another execution). It is the actual instance of the Workflow Definition running in the Temporal Platform.
+
+You'll develop those Workflows by writing code in a general-purpose programming language such as Go, Java, TypeScript,
+or Python. The code you write is the same code that will be executed at runtime, so you can use your favorite tools and
+libraries to develop Temporal Workflows.
+
+Temporal Workflows are resilient. They can run—and keep running—for years, even if the underlying infrastructure fails.
+If the application itself crashes, Temporal will automatically recreate its pre-failure state so it can continue right
+where it left off.
+
+Each Workflow Execution progresses through a series of **Commands** and **Events**, which are recorded in an **Event
+History**.
 
 Workflows must follow deterministic constraints to ensure consistent replay behavior.

docs/evaluate/temporal-cloud/limits.mdx

@@ -185,8 +185,8 @@ For more information on custom Search Attributes see [Custom Search Attributes l
 
 ### Nexus Endpoints limits
 
-By default, each account is provisioned with 10 Nexus Endpoints.
-You can request further increases beyond the initial 10 Endpoint limit by [opening a support ticket](/cloud/support#support-ticket).
+By default, each account is provisioned with 100 Nexus Endpoints.
+You can request further increases beyond the initial 100 Endpoint limit by [opening a support ticket](/cloud/support#support-ticket).
 
 ## Programming model level
 

docs/evaluate/temporal-cloud/service-availability.mdx

@@ -40,17 +40,27 @@ Please contact your AE or Support to enable this feature.
 
 Temporal Cloud has a p99 latency SLO of 200ms per region.
 
-In March 2024, latency over a week-long period for starting and signaling Workflow Executions was as follows:
+The same SLO for normal Worker requests (commands and polling) apply to Nexus in both the caller and handler Namespaces.
+
+### Historical latency data
+
+Latency over a week-long period for starting and signaling Workflow Executions was as follows:
+
+#### January 2026
+
+| Operation                          |  p50   | p90  |  p99 |
+| :--------------------------------- | :----: | :--: | ---: |
+| `StartWorkflowExecution`           | 14ms | 21ms | 69ms |
+| `SignalWorkflowExecution`          | 11ms | 19ms | 46ms |
+| `SignalWithStartWorkflowExecution` | 19ms | 37ms | 95ms |
+
+#### March 2024
 
 | Operation                          | p90  |  p99 |
 | :--------------------------------- | :--: | ---: |
 | `StartWorkflowExecution`           | 24ms | 54ms |
 | `SignalWorkflowExecution`          | 14ms | 40ms |
 | `SignalWithStartWorkflowExecution` | 24ms | 61ms |
 
-As Temporal continues working on improving latencies, these numbers will progressively decrease.
-
-The same SLO for normal Worker requests (commands and polling) apply to Nexus in both the caller and handler Namespaces.
-
 Latency observed from the Temporal Client is influenced by other system components like the Codec Server, egress proxy, and the network itself.
 Also, concurrent operations on the same Workflow Execution may result in higher latency.

docs/evaluate/temporal-cloud/support.mdx

@@ -22,7 +22,6 @@ Temporal Cloud includes the right level of technical support and guidance, servi
 Our team has extensive knowledge of Temporal, and a broad set of skills to help you succeed with any project.
 
 Temporal Cloud provides several levels of support, from assisting with for break/fix scenarios to issues and services to helping with onboarding, design/code reviews for your application, and pre-production optimizations and operational readiness.
-note
 
 :::note