Merge branch 'main' into fix-regional-endpoints

Author: lennessyy

docs/cloud/billing-and-usage/billing-api.mdx

@@ -20,7 +20,7 @@ This API is part of the [Cloud Operations API](/ops).
 
 :::tip Support, stability, and dependency info
 
-The Temporal Cloud Billing API is in [Pre-release](/evaluate/development-production-features/release-stages#pre-release).
+The Temporal Cloud Billing API is in [Public Preview](/evaluate/development-production-features/release-stages#public-preview).
 
 :::
 
@@ -33,7 +33,7 @@ The Billing API allows you to:
 The Billing Report contains:
 
 - Accurate Namespace-level cost attribution  
-- Hourly granularity  
+- Hourly, daily, and monthly granularities
 - A [FOCUS](https://focus.finops.org/)-friendly data format
 
 For complete request and response schemas, refer to the Schema below.
@@ -42,7 +42,10 @@ Billing report generation is **asynchronous**. You initiate report creation, the
 
 ## Report data limitations
 
-For pre-release, reports can be generated with hourly granularity only, for the current billing month, and the previous billing month.
+For public preview, reports can be generated with hourly, daily and monthly granularities, each of which have their own data ranges.
+- Hourly: Current billing month and previous billing month
+- Daily: Current billing month and previous two billing months
+- Monthly: Current billing month and previous eleven billing months
 
 ## Allowed date ranges
 

docs/cloud/billing-and-usage/billing.mdx

@@ -87,7 +87,7 @@ The following information appears under the credits table:
 
 ## Cost by Namespace {#cost-by-namespace}
 
-:::tip Temporal Cloud Billing API in Pre-release
+:::tip Temporal Cloud Billing API in Public Preview
 
 The [Temporal Cloud Billing API](/cloud/billing-api) allows you to access billing information on a Namespace basis to an hourly granularity, enriched with Tags and Projects. The Billing API will replace the Cost by Namespace UI.
 

docs/cloud/billing-and-usage/index.mdx

@@ -44,7 +44,7 @@ The following tools are available for measuring Usage and Billing:
 
 :::tip Support, stability, and dependency info
 
-The Temporal Cloud Billing API is in [Pre-release](/evaluate/development-production-features/release-stages#pre-release).
+The Temporal Cloud Billing API is in [Public Preview](/evaluate/development-production-features/release-stages#public-preview).
 
 :::
 

docs/cloud/manage-access/roles-and-permissions.mdx

@@ -36,7 +36,7 @@ The following table provides a summary of the account-level roles and their prim
 | Account Owner | Owns and governs the account                | Yes                   | All Namespaces (cannot be revoked)      | Full billing, payments, and usage |
 | Global Admin  | Administers account configuration and users | Yes                   | All Namespaces (cannot be revoked)      | Usage only                        |
 | Developer     | Creates and manages Namespaces they own     | Yes                   | Namespaces they create (can be revoked) | None                              |
-| Finance Admin | Manages billing and payment information     | No                    | None                                    | Full billing and payments         |
+| Finance Admin | Manages billing and payment information     | No                    | None                                    | Full billing, payments, and usage         |
 | Read-Only     | Views account configuration and resources   | No                    | None                                    | None                              |
 
 Account-level roles don't govern day-to-day operations within a Namespace. Access to resources inside a Namespace, such

docs/develop/dotnet/workflows/child-workflows.mdx

@@ -40,8 +40,9 @@ A [Child Workflow Execution](/child-workflows) is a Workflow Execution that is s
 
 When using a Child Workflow API, Child Workflow related Events ([StartChildWorkflowExecutionInitiated](/references/events#startchildworkflowexecutioninitiated), [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted), [ChildWorkflowExecutionCompleted](/references/events#childworkflowexecutioncompleted), etc...) are logged in the Workflow Execution Event History.
 
-Always block progress until the [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted) Event is logged to the Event History to ensure the Child Workflow Execution has started.
-After that, Child Workflow Executions may be abandoned using the _Abandon_ [Parent Close Policy](/parent-close-policy) set in the Child Workflow Options.
+The [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted) Event must be logged to the Event History before the Parent Workflow completes to ensure the Child Workflow has started.
+In .NET, awaiting `StartChildWorkflowAsync()` or `ExecuteChildWorkflowAsync()` internally waits for this Event before returning, so the Child Workflow is guaranteed to have started once the call resolves.
+If you start a Child Workflow from a non-main context (for example, a Signal or Update handler), make sure the Parent Workflow doesn't complete before that call resolves.
 
 To spawn a Child Workflow Execution in .NET, use the `ExecuteChildWorkflowAsync()` method which starts the Child Workflow and waits for completion or
 use the `StartChildWorkflowAsync()` method to start a Child Workflow and return its handle.

docs/develop/go/workers/run-worker-process.mdx

@@ -22,7 +22,8 @@ Create a [`Worker`](https://pkg.go.dev/go.temporal.io/sdk/worker#Worker) by call
 2. The name of the Task Queue to poll.
 3. A [`worker.Options`](https://pkg.go.dev/go.temporal.io/sdk/internal#WorkerOptions) struct (can be empty for defaults).
 
-Register your Workflow and Activity types, then call `Run()` to start polling.
+Register your Workflow and Activity types, then call `Run()` to start polling. The Worker process is a long-running process that blocks while polling for tasks.
+Run it in a separate terminal from your starter code or other application logic.
 
 ```go
 package main

docs/develop/go/workflows/child-workflows.mdx

@@ -24,12 +24,9 @@ A [Child Workflow Execution](/child-workflows) is a Workflow Execution that is s
 
 When using a Child Workflow API, Child Workflow related Events ([StartChildWorkflowExecutionInitiated](/references/events#startchildworkflowexecutioninitiated), [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted), [ChildWorkflowExecutionCompleted](/references/events#childworkflowexecutioncompleted), etc...) are logged in the Workflow Execution Event History.
 
-Always block progress until the [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted) Event is logged to the Event History to ensure the Child Workflow Execution has started.
-After that, Child Workflow Executions may be abandoned using the _Abandon_ [Parent Close Policy](/parent-close-policy) set in the Child Workflow Options.
-
-To be sure that the Child Workflow Execution has started, first call the Child Workflow Execution method on the instance of Child Workflow future, which returns a different future.
-
-Then get the value of an object that acts as a proxy for a result that is initially unknown, which is what waits until the Child Workflow Execution has spawned.
+The [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted) Event must be logged to the Event History before the Parent Workflow completes to ensure the Child Workflow has started.
+In Go, you must explicitly call `GetChildWorkflowExecution()` on the `ChildWorkflowFuture` and then call `Get()` on the returned Future to wait for this Event.
+See the [Async Child Workflows](#async-child-workflows) section below for a complete example.
 
 To spawn a [Child Workflow Execution](/child-workflows) in Go, use the [`ExecuteChildWorkflow`](https://pkg.go.dev/go.temporal.io/sdk/workflow#ExecuteChildWorkflow) API, which is available from the `go.temporal.io/sdk/workflow` package.
 

docs/develop/java/workflows/child-workflows.mdx

@@ -24,12 +24,9 @@ A [Child Workflow Execution](/child-workflows) is a Workflow Execution that is s
 
 When using a Child Workflow API, Child Workflow related Events ([StartChildWorkflowExecutionInitiated](/references/events#startchildworkflowexecutioninitiated), [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted), [ChildWorkflowExecutionCompleted](/references/events#childworkflowexecutioncompleted), etc...) are logged in the Workflow Execution Event History.
 
-Always block progress until the [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted) Event is logged to the Event History to ensure the Child Workflow Execution has started.
-After that, Child Workflow Executions may be abandoned using the _Abandon_ [Parent Close Policy](/parent-close-policy) set in the Child Workflow Options.
-
-To be sure that the Child Workflow Execution has started, first call the Child Workflow Execution method on the instance of Child Workflow future, which returns a different future.
-
-Then get the value of an object that acts as a proxy for a result that is initially unknown, which is what waits until the Child Workflow Execution has spawned.
+The [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted) Event must be logged to the Event History before the Parent Workflow completes to ensure the Child Workflow has started.
+In Java, you must explicitly call `Workflow.getWorkflowExecution(child)` to get a `Promise`, then call `.get()` on that Promise to wait for this Event.
+See the [Parent Close Policy](#parent-close-policy) section below for a complete example.
 
 ### Async Child Workflows
 

docs/develop/php/workflows/child-workflows.mdx

@@ -20,12 +20,9 @@ A [Child Workflow Execution](/child-workflows) is a Workflow Execution that is s
 
 When using a Child Workflow API, Child Workflow related Events ([StartChildWorkflowExecutionInitiated](/references/events#startchildworkflowexecutioninitiated), [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted), [ChildWorkflowExecutionCompleted](/references/events#childworkflowexecutioncompleted), etc...) are logged in the Workflow Execution Event History.
 
-Always block progress until the [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted) Event is logged to the Event History to ensure the Child Workflow Execution has started.
-After that, Child Workflow Executions may be abandoned using the _Abandon_ [Parent Close Policy](/parent-close-policy) set in the Child Workflow Options.
-
-To be sure that the Child Workflow Execution has started, first call the Child Workflow Execution method on the instance of Child Workflow future, which returns a different future.
-
-Then get the value of an object that acts as a proxy for a result that is initially unknown, which is what waits until the Child Workflow Execution has spawned.
+The [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted) Event must be logged to the Event History before the Parent Workflow completes to ensure the Child Workflow has started.
+In PHP, yielding `$child->start()` or `Workflow::executeChildWorkflow()` internally waits for this Event before returning, so the Child Workflow is guaranteed to have started once the yield resolves.
+See the [Parent Close Policy](#parent-close-policy) section below for an example.
 
 Besides Activities, a Workflow can also start other Workflows.
 

docs/develop/python/workflows/child-workflows.mdx

@@ -32,12 +32,9 @@ A [Child Workflow Execution](/child-workflows) is a Workflow Execution that is s
 
 When using a Child Workflow API, Child Workflow related Events ([StartChildWorkflowExecutionInitiated](/references/events#startchildworkflowexecutioninitiated), [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted), [ChildWorkflowExecutionCompleted](/references/events#childworkflowexecutioncompleted), etc...) are logged in the Workflow Execution Event History.
 
-Always block progress until the [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted) Event is logged to the Event History to ensure the Child Workflow Execution has started.
-After that, Child Workflow Executions may be abandoned using the _Abandon_ [Parent Close Policy](/parent-close-policy) set in the Child Workflow Options.
-
-To be sure that the Child Workflow Execution has started, first call the Child Workflow Execution method on the instance of Child Workflow future, which returns a different future.
-
-Then get the value of an object that acts as a proxy for a result that is initially unknown, which is what waits until the Child Workflow Execution has spawned.
+The [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted) Event must be logged to the Event History before the Parent Workflow completes to ensure the Child Workflow has started.
+In Python, awaiting `start_child_workflow()` or `execute_child_workflow()` internally waits for this Event before returning, so the Child Workflow is guaranteed to have started once the call resolves.
+If you start a Child Workflow from a non-main coroutine (for example, a Signal or Update handler), make sure the Parent Workflow doesn't complete before that call resolves.
 
 To spawn a Child Workflow Execution in Python, use the [`execute_child_workflow()`](https://python.temporal.io/temporalio.workflow.html#execute_child_workflow) function which starts the Child Workflow and waits for completion or
 use the [`start_child_workflow()`](https://python.temporal.io/temporalio.workflow.html#start_child_workflow) function to start a Child Workflow and return its handle.