Merge branch 'main' into maplexu/AI-141-langsmith-docs

Author: xumaple

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,13 +42,16 @@ 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
 
 Date ranges must use billing-month boundaries (MM/YYYY). 
 Requests may include the current billing month. 
-The data in finalized reports includes usage up to `current_time` \- 24 hours (rounded up to nearest hour).
+The data in finalized reports includes usage up to `current_time` \- 24 hours (rounded down to the granularity level).
 
 ## Rate limits and concurrency
 

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/best-practices/python-sdk-sandbox.mdx

@@ -111,7 +111,7 @@ The [`SandboxRestrictions`](https://python.temporal.io/temporalio.worker.workflo
 By default, the sandbox completely reloads non-standard-library and non-Temporal modules for every Workflow run. Passing through a module means that the module will not be reloaded every time the Workflow runs. Instead, the module will be imported from outside the sandbox and used directly in the Workflow. This can improve performance because importing a module can be a time-consuming process, and passing through a module can avoid this overhead.
 
 :::note
-It is important to note that you should only import _known-side-effect-free_ third-party modules: meaning they don't have any unintended consequences when imported and used multiple times. This is because passing through a module means that it will be used multiple times in a workflow without being reloaded, so any side effects it has will be repeated. For this reason, it's recommended to only pass through modules that are known to be deterministic, meaning they will always produce the same output given the same input.
+It is important to note that you should only import _known-side-effect-free_ third-party modules: meaning they don't have any unintended consequences when imported and used multiple times. This is because passing through a module means that it will be used multiple times in a Workflow without being reloaded, so any side effects it has won't be repeated. For this reason, it's recommended to only pass through modules that are known to be deterministic, meaning they will always produce the same output given the same input.
 :::
 
 One way to pass through a module is at import time in the Workflow file using the [`imports_passed_through`](https://python.temporal.io/temporalio.workflow.unsafe.html#imports_passed_through) context manager.