From d3e3f88c7816e4af6dd4ca4781d0e48b1ca9e3a6 Mon Sep 17 00:00:00 2001 From: Jwahir Sundai Date: Mon, 31 Aug 2026 12:15:06 -0500 Subject: [PATCH 1/2] structure standardization --- docs/develop/dotnet/workflows/basics.mdx | 58 ++++++++++---------- docs/develop/go/client/temporal-client.mdx | 2 +- docs/develop/go/workflows/basics.mdx | 20 +++---- docs/develop/java/workflows/basics.mdx | 8 +-- docs/develop/php/workflows/basics.mdx | 18 +++--- docs/develop/python/workflows/basics.mdx | 22 ++++---- docs/develop/ruby/workflows/basics.mdx | 8 +-- docs/develop/rust/workflows/basics.mdx | 16 +++--- docs/develop/typescript/workflows/basics.mdx | 21 ++++--- 9 files changed, 86 insertions(+), 87 deletions(-) diff --git a/docs/develop/dotnet/workflows/basics.mdx b/docs/develop/dotnet/workflows/basics.mdx index 6e8e210088..109fca7fa2 100644 --- a/docs/develop/dotnet/workflows/basics.mdx +++ b/docs/develop/dotnet/workflows/basics.mdx @@ -2,14 +2,14 @@ id: basics title: Workflow basics - .NET SDK sidebar_label: Workflow basics -description: This section explains Workflow basics with the .NET SDK +description: Develop a basic Workflow with the Temporal .NET SDK. Define Workflow parameters, return values, and a custom Workflow Type. toc_max_heading_level: 4 tags: - .NET SDK - Temporal SDKs --- -## Develop a Workflow {/* #develop-workflow */} +## Develop a basic Workflow {/* #develop-workflows */} Workflows are the fundamental unit of a Temporal Application, and it all starts with the development of a [Workflow Definition](/workflow-definition). @@ -40,7 +40,31 @@ Temporal Workflows may have any number of custom parameters. However, we strongly recommend that objects are used as parameters, so that the object's individual fields may be altered without breaking the signature of the Workflow. All Workflow Definition parameters must be serializable. -### Use Workflow constructors +## Customize Workflow Type {/* #workflow-type */} + +Workflows have a Type that are referred to as the Workflow name. + +The following examples demonstrate how to set a custom name for your Workflow Type. + +You can customize the Workflow name with a custom name in the attribute. For example, `[Workflow("my-workflow-name")]`. If the name parameter is not specified, the Workflow name defaults to the unqualified class name. + +```csharp +using Temporalio.Workflows; + +[Workflow("MyDifferentWorkflowName")] +public class MyWorkflow +{ + public async Task RunAsync(string name) + { + var param = MyActivityParams("Hello", name); + return await Workflow.ExecuteActivityAsync( + (MyActivities a) => a.MyActivity(param), + new() { StartToCloseTimeout = TimeSpan.FromMinutes(5) }); + } +} +``` + +## Use Workflow constructors Workflow constructors are useful if you have message handlers that need access to Workflow input: see [Initializing the Workflow first](/handling-messages#workflow-initializers). Normally, your Workflows constructor won't have any parameters. The `[WorkflowInit]` attribute gives message handlers access to Workflow input. When you use the `[WorkflowInit]` attribute on your constructor, you give the constructor the same Workflow parameters as your `[WorkflowRun]` method. @@ -155,7 +179,7 @@ If your goal is to always take action when something new is happening, check tha is false instead. That is false during read-only operations like Queries and Update validators. This is what the SDK's built-in logger and tracing interceptors use internally. -### .NET Task Determinism +## .NET Task Determinism Some calls in .NET do unsuspecting non-deterministic things and are easy to accidentally use. This is especially true with `Task`s. @@ -191,7 +215,7 @@ In the near future for modern .NET versions we hope to use the [new `TimeProvider` API](https://github.com/dotnet/runtime/issues/36617) which will allow us to control current time and timers. -### Workflow .editorconfig +## Workflow .editorconfig Since Workflow code follows some different logic rules than regular C# code, there are some common analyzer rules that developers may want to disable. To ensure these are only disabled for Workflows, current recommendation is to use the `.workflow.cs` extension for files containing Workflows. @@ -239,27 +263,3 @@ dotnet_diagnostic.CS1998.severity = none # Don't avoid, but rather encourage things using TaskScheduler.Current in workflows dotnet_diagnostic.VSTHRD105.severity = none ``` - -### Customize Workflow Type {/* #workflow-type */} - -Workflows have a Type that are referred to as the Workflow name. - -The following examples demonstrate how to set a custom name for your Workflow Type. - -You can customize the Workflow name with a custom name in the attribute. For example, `[Workflow("my-workflow-name")]`. If the name parameter is not specified, the Workflow name defaults to the unqualified class name. - -```csharp -using Temporalio.Workflows; - -[Workflow("MyDifferentWorkflowName")] -public class MyWorkflow -{ - public async Task RunAsync(string name) - { - var param = MyActivityParams("Hello", name); - return await Workflow.ExecuteActivityAsync( - (MyActivities a) => a.MyActivity(param), - new() { StartToCloseTimeout = TimeSpan.FromMinutes(5) }); - } -} -``` diff --git a/docs/develop/go/client/temporal-client.mdx b/docs/develop/go/client/temporal-client.mdx index c0e60f8d21..4bf19d6db0 100644 --- a/docs/develop/go/client/temporal-client.mdx +++ b/docs/develop/go/client/temporal-client.mdx @@ -573,7 +573,7 @@ In the examples below, all Workflow Executions are started using a Temporal Clie within another Workflow Execution, use either the [Child Workflow](/develop/go/workflows/child-workflows) or External Workflow APIs. -See the [Customize Workflow Type](/develop/go/workflows/basics#customize-workflow-type) section to see how to customize +See the [Customize Workflow Type](/develop/go/workflows/basics#workflow-type) section to see how to customize the name of the Workflow Type. A request to spawn a Workflow Execution causes the Temporal Service to create the first Event diff --git a/docs/develop/go/workflows/basics.mdx b/docs/develop/go/workflows/basics.mdx index ba405b791d..f8b906c144 100644 --- a/docs/develop/go/workflows/basics.mdx +++ b/docs/develop/go/workflows/basics.mdx @@ -2,14 +2,14 @@ id: basics title: Workflow basics - Go SDK sidebar_label: Workflow basics -description: This section explains Workflow basics with the Go SDK +description: Develop a basic Workflow with the Temporal Go SDK. Define Workflow parameters, return values, and a custom Workflow Type. toc_max_heading_level: 4 tags: - Go SDK - Temporal SDKs --- -## How to develop a basic Workflow {/* #develop-workflows */} +## Develop a basic Workflow {/* #develop-workflows */} Workflows are the fundamental unit of a Temporal Application, and it all starts with the development of a [Workflow Definition](/workflow-definition). @@ -30,7 +30,7 @@ func YourSimpleWorkflowDefinition(ctx workflow.Context) error { } ``` -### How to define Workflow parameters {/* #workflow-parameters */} +## Define Workflow parameters {/* #workflow-parameters */} Temporal Workflows may have any number of custom parameters. However, we strongly recommend that objects are used as parameters, so that the object's individual fields may be altered without breaking the signature of the Workflow. @@ -86,7 +86,7 @@ func YourWorkflowDefinition(ctx workflow.Context, param YourWorkflowParam) (*You } ``` -### How to define Workflow return parameters {/* #workflow-return-values */} +## Define Workflow return values {/* #workflow-return-values */} Workflow return values must also be serializable. Returning results, returning errors, or throwing exceptions is fairly idiomatic in each language that is supported. @@ -142,7 +142,7 @@ func YourWorkflowDefinition(ctx workflow.Context, param YourWorkflowParam) (*You } ``` -### How to customize Workflow Type in Go {/* #customize-workflow-type */} +## Customize Workflow Type {/* #workflow-type */} In Go, by default, the Workflow Type name is the same as the function name. @@ -196,7 +196,7 @@ func main() { } ``` -### How to develop Workflow logic {/* #workflow-logic-requirements */} +## Workflow logic requirements {/* #workflow-logic-requirements */} 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. @@ -221,7 +221,7 @@ The Temporal Go SDK has APIs to handle equivalent Go constructs: - `workflow.Context` This is a replacement for `context.Context`. See [Tracing](/develop/go/platform/observability#tracing) for more information about context propagation. -#### Logging +### Logging Use [`workflow.GetLogger(ctx)`](https://pkg.go.dev/go.temporal.io/sdk/workflow#GetLogger) instead of the standard `log` package or `fmt.Println`. The SDK logger skips log messages during replay to avoid duplicates: @@ -236,7 +236,7 @@ func MyWorkflow(ctx workflow.Context, name string) (string, error) { For logger configuration, see [Observability: Log from a Workflow](/develop/go/platform/observability#logging). -#### Random numbers and UUIDs +### Random numbers and UUIDs The Go SDK does not provide a seeded random source or a UUID helper. Generate these inside a [Side Effect](/develop/go/workflows/side-effects), which records the result in the Event History and returns the @@ -253,7 +253,7 @@ encodedID.Get(&id) An Activity works for this too, and is the better choice when the value comes from an external system. A Side Effect is cheaper for purely local generation. -#### Current time +### Current time Use [`workflow.Now(ctx)`](https://pkg.go.dev/go.temporal.io/sdk/workflow#Now) instead of `time.Now()`. It returns the time of the last Workflow Task, which is consistent across replays: @@ -264,7 +264,7 @@ currentTime := workflow.Now(ctx) To wait, use [`workflow.Sleep(ctx, d)`](https://pkg.go.dev/go.temporal.io/sdk/workflow#Sleep) instead of `time.Sleep`. -#### Detecting replay (advanced) +### Detecting replay (advanced) Use [`workflow.IsReplaying(ctx)`](https://pkg.go.dev/go.temporal.io/sdk/workflow#IsReplaying) to guard code that should only run on the first execution, such as emitting metrics or sending external notifications from an Interceptor. diff --git a/docs/develop/java/workflows/basics.mdx b/docs/develop/java/workflows/basics.mdx index 6ecdc2c838..2588b25451 100644 --- a/docs/develop/java/workflows/basics.mdx +++ b/docs/develop/java/workflows/basics.mdx @@ -2,14 +2,14 @@ id: basics title: Workflow basics - Java SDK sidebar_label: Workflow basics -description: This section explains how to implement Workflows with the Java SDK +description: Develop a basic Workflow with the Temporal Java SDK. Define Workflow parameters, return values, and a custom Workflow Type. toc_max_heading_level: 4 tags: - Java SDK - Temporal SDKs --- -## How to develop a Workflow {/* #develop-workflows */} +## Develop a basic Workflow {/* #develop-workflows */} Workflows are the fundamental unit of a Temporal Application, and it all starts with the development of a [Workflow Definition](/workflow-definition). @@ -158,7 +158,7 @@ public interface YourWorkflow { } ``` -## Define Workflow return parameters {/* #workflow-return-values */} +## Define Workflow return values {/* #workflow-return-values */} Workflow return values must also be serializable. Returning results, returning errors, or throwing exceptions is fairly idiomatic in each language that is supported. @@ -174,7 +174,7 @@ Related references: - [Data Converter](/dataconversion) - [Java DataConverter reference](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/common/converter/DataConverter.html) -## Customize your Workflow Type {/* #workflow-type */} +## Customize Workflow Type {/* #workflow-type */} Workflows have a Type that is referred to as the Workflow name. diff --git a/docs/develop/php/workflows/basics.mdx b/docs/develop/php/workflows/basics.mdx index 2d9a777ffb..588cf85d5f 100644 --- a/docs/develop/php/workflows/basics.mdx +++ b/docs/develop/php/workflows/basics.mdx @@ -1,15 +1,15 @@ --- id: basics -title: Workflow Basics - PHP SDK -sidebar_label: Workflow Basics -description: This section explains Workflow Basics with the PHP SDK +title: Workflow basics - PHP SDK +sidebar_label: Workflow basics +description: Develop a basic Workflow with the Temporal PHP SDK. Define Workflow parameters, return values, and a custom Workflow Type. toc_max_heading_level: 4 tags: - PHP SDK - Temporal SDKs --- -## How to develop a basic Workflow {/* #develop-workflows */} +## Develop a basic Workflow {/* #develop-workflows */} Workflows are the fundamental unit of a Temporal Application, and it all starts with the development of a [Workflow Definition](/workflow-definition). @@ -28,7 +28,7 @@ interface FileProcessingWorkflow } ``` -### How to define Workflow parameters {/* #workflow-parameters */} +## Define Workflow parameters {/* #workflow-parameters */} Temporal Workflows may have any number of custom parameters. However, we strongly recommend that objects are used as parameters, so that the object's individual fields may be altered without breaking the signature of the Workflow. @@ -50,7 +50,7 @@ interface FileProcessingWorkflow { } ``` -### How to define Workflow return parameters {/* #workflow-return-values */} +## Define Workflow return values {/* #workflow-return-values */} Workflow return values must also be serializable. Returning results, returning errors, or throwing exceptions is fairly idiomatic in each language that is supported. @@ -69,7 +69,7 @@ interface FileProcessingWorkflow { } ``` -### How to customize your Workflow Type {/* #workflow-type */} +## Customize Workflow Type {/* #workflow-type */} Workflows have a Type that are referred to as the Workflow name. @@ -92,7 +92,7 @@ interface YourWorkflowDefinitionInterface } ``` -### Use Workflow constructors +## Use Workflow constructors Workflow constructors are useful if you have message handlers that need access to Workflow input: see [Initializing the Workflow first](/handling-messages#workflow-initializers). Normally, your Workflows constructor won't have any parameters. However, if you use the `#[WorkflowInit]` attribute on your constructor, you can give it the same [Workflow parameters](/develop/php/workflows/basics#workflow-parameters) as your `#[WorkflowMethod]`. @@ -127,7 +127,7 @@ class GreetingExample } ``` -### How to develop Workflow logic {/* #workflow-logic-requirements */} +## Workflow logic requirements {/* #workflow-logic-requirements */} 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. used inside your Workflow to interact with external (to the Workflow) application code. diff --git a/docs/develop/python/workflows/basics.mdx b/docs/develop/python/workflows/basics.mdx index 9c925ebca7..20ed6f5f8d 100644 --- a/docs/develop/python/workflows/basics.mdx +++ b/docs/develop/python/workflows/basics.mdx @@ -1,8 +1,8 @@ --- id: basics -title: Workflow Basics - Python SDK +title: Workflow basics - Python SDK sidebar_label: Workflow basics -description: This section explains Workflow Basics with the Python SDK +description: Develop a basic Workflow with the Temporal Python SDK. Define Workflow parameters, return values, and a custom Workflow Type. toc_max_heading_level: 4 tags: - Python SDK @@ -41,7 +41,7 @@ class YourWorkflow: ) ``` -### Define Workflow parameters {/* #workflow-parameters */} +## Define Workflow parameters {/* #workflow-parameters */} Temporal Workflows may have any number of custom parameters. However, we strongly recommend that objects are used as parameters, so that the object's individual fields may be altered without breaking the signature of the Workflow. All @@ -61,7 +61,7 @@ class YourParams: name: str ``` -### Define Workflow return parameters {/* #workflow-return-values */} +## Define Workflow return values {/* #workflow-return-values */} Workflow return values must also be serializable. Returning results, returning errors, or throwing exceptions is fairly idiomatic in each language that is supported. However, Temporal APIs that must be used to get the result of a Workflow @@ -98,7 +98,7 @@ class YourWorkflow: ) ``` -### Customize your Workflow Type {/* #workflow-type */} +## Customize Workflow Type {/* #workflow-type */} Workflows have a Type that are referred to as the Workflow name. @@ -126,7 +126,7 @@ class YourWorkflow: ) ``` -### Use Workflow constructors +## Use Workflow constructors Workflow constructors are useful if you have message handlers that need access to Workflow input: see [Initializing the Workflow first](/handling-messages#workflow-initializers). Normally, your Workflow `__init__` method won't have any parameters. However, if you use the `@workflow.init` decorator on your `__init__` method, you can give it the same Workflow parameters as your `@workflow.run` method. @@ -155,7 +155,7 @@ class WorkflowRunSeesWorkflowInitWorkflow: # other Workflow code ``` -### Develop Workflow logic {/* #workflow-logic-requirements */} +## Workflow logic requirements {/* #workflow-logic-requirements */} Workflow logic is constrained by [deterministic execution requirements](/workflow-definition#deterministic-constraints). Each Temporal SDK provides a @@ -176,7 +176,7 @@ _deterministic_. The SDK provides replay-safe alternatives for common needs: -#### Logging +### Logging Use [`workflow.logger`](https://python.temporal.io/temporalio.workflow.html#logger) instead of `print()` or the standard `logging` module. The SDK logger automatically suppresses log messages during replay to avoid duplicates: @@ -192,7 +192,7 @@ class MyWorkflow: For logger configuration, see [Observability: Log from a Workflow](/develop/python/platform/observability#logging). -#### Random numbers and UUIDs +### Random numbers and UUIDs Use [`workflow.random()`](https://python.temporal.io/temporalio.workflow.html#random) to get a deterministic `random.Random` instance seeded per Workflow Execution. Never use `random.random()` or other `random` module functions directly. For UUIDs, use [`workflow.uuid4()`](https://python.temporal.io/temporalio.workflow.html#uuid4) instead of `uuid.uuid4()`: @@ -202,7 +202,7 @@ value = workflow.random().randint(1, 100) unique_id = workflow.uuid4() ``` -#### Current time +### Current time Use [`workflow.now()`](https://python.temporal.io/temporalio.workflow.html#now) instead of `datetime.now()` or `time.time()`. The SDK returns the time of the last Workflow Task, which is consistent across replays: @@ -210,7 +210,7 @@ Use [`workflow.now()`](https://python.temporal.io/temporalio.workflow.html#now) current_time = workflow.now() ``` -#### Detecting replay (advanced) +### Detecting replay (advanced) Use [`workflow.unsafe.is_replaying`](https://python.temporal.io/temporalio.workflow.html#is_replaying) to guard code that should only run on the first execution, such as emitting metrics or sending external notifications from an [Interceptor](/develop/python/workers/interceptors). :::caution diff --git a/docs/develop/ruby/workflows/basics.mdx b/docs/develop/ruby/workflows/basics.mdx index b66f3bae64..1e38965336 100644 --- a/docs/develop/ruby/workflows/basics.mdx +++ b/docs/develop/ruby/workflows/basics.mdx @@ -2,14 +2,14 @@ id: basics title: Workflow basics - Ruby SDK sidebar_label: Workflow basics -description: This section explains Workflow basics with the Ruby SDK +description: Develop a basic Workflow with the Temporal Ruby SDK. Define Workflow parameters, return values, and a custom Workflow Type. toc_max_heading_level: 4 tags: - Ruby SDK - Temporal SDKs --- -## Develop a Workflow {/* #develop-workflow */} +## Develop a basic Workflow {/* #develop-workflows */} Workflows are the fundamental unit of a Temporal Application, and it all starts with the development of a [Workflow Definition](/workflow-definition). @@ -34,7 +34,7 @@ end Temporal Workflows may have any number of custom parameters. However, we strongly recommend that hashes or objects are used as parameters, so that the object's individual fields may be altered without breaking the signature of the Workflow. -### Customize Workflow Type {/* #workflow-type */} +## Customize Workflow Type {/* #workflow-type */} Workflows have a Type that are referred to as the Workflow name. @@ -58,7 +58,7 @@ class MyWorkflow < Temporalio::Workflow::Definition end ``` -### Use Workflow constructors +## Use Workflow constructors Workflow constructors are useful if you have message handlers that need access to Workflow input: see [Initializing the Workflow first](/handling-messages#workflow-initializers). The `workflow_init` class method above `initialize` gives it access to [Workflow input](/handling-messages#workflow-initializers). When you use the `workflow_init` on your constructor, you give the constructor the same Workflow parameters as your `execute` method. diff --git a/docs/develop/rust/workflows/basics.mdx b/docs/develop/rust/workflows/basics.mdx index be56149cb6..a4cd3c01f4 100644 --- a/docs/develop/rust/workflows/basics.mdx +++ b/docs/develop/rust/workflows/basics.mdx @@ -2,14 +2,14 @@ id: basics title: Workflow basics - Rust SDK sidebar_label: Workflow basics -description: This section explains how to implement Workflows with the Rust SDK +description: Develop a basic Workflow with the Temporal Rust SDK. Define Workflow parameters, return values, and a custom Workflow Type. toc_max_heading_level: 4 tags: - Rust SDK - Temporal SDKs --- -## How to develop a Workflow {/* #develop-workflows */} +## Develop a basic Workflow {/* #develop-workflows */} Workflows are the fundamental unit of a Temporal Application and it all starts with the development of a [Workflow Definition](/workflow-definition). @@ -48,11 +48,11 @@ impl GreetingWorkflow { The `#[workflow]` macro marks the struct as a Workflow. The `#[workflow_methods]` macro is applied to the `impl` block containing the Workflow methods. -### Workflow struct {/* #workflow-struct */} +## Workflow struct {/* #workflow-struct */} The Workflow struct holds the state of your Workflow Execution. This state is persisted and recovered during replays. All fields in a Workflow struct should be serializable. -### Workflow initialization {/* #init-method */} +## Workflow initialization {/* #init-method */} The `#[init]` method is optional and is called when the Workflow first starts. It receives the initial Workflow input parameters and initializes the Workflow struct: @@ -69,7 +69,7 @@ fn new(ctx: &WorkflowContextView, name: String, age: u32) -> Self { The `#[init]` method receives a `WorkflowContextView`, which provides read-only access to Workflow execution information. -#### Use Workflow constructors +## Use Workflow constructors Workflow constructors are useful if you have message handlers that need access to Workflow input: see [Initializing the Workflow first](/handling-messages#workflow-initializers). Normally, your Workflows constructor won't have any parameters. However, if you use the `#[init]` annotation on your constructor, you can give it the same [Workflow parameters](/develop/rust/workflows/basics#workflow-parameters) as your `#[run]`. @@ -102,7 +102,7 @@ impl WorkflowRunSeesWorkflowInitWorkflow { } ``` -### Run method {/* #run-method */} +## Run method {/* #run-method */} The `#[run]` method is required and contains the main Workflow logic. It: @@ -169,7 +169,7 @@ impl ProcessingWorkflow { All Workflow input should be serializable by `serde`. -## Define Workflow return parameters {/* #workflow-return-values */} +## Define Workflow return values {/* #workflow-return-values */} Workflow return values must also be serializable. Returning results, returning errors, or throwing exceptions is fairly idiomatic in each language that is supported. However, Temporal APIs that must be used to get the result of a Workflow Execution will only ever receive one of either the result or the error. @@ -188,7 +188,7 @@ async fn run(ctx: &mut WorkflowContext) -> WorkflowResult } ``` -## How to define Workflow parameters {/* #workflow-parameters */} +## Define Workflow parameters {/* #workflow-parameters */} Temporal Workflows may have any number of custom parameters. However, we strongly recommend that objects are used as parameters, so that the object's individual fields may be altered without breaking the signature of the Workflow. All @@ -71,7 +70,7 @@ export async function example({ name, born }: ExampleParam): Promise { } ``` -## How to define Workflow return parameters {/* #workflow-return-values */} +## Define Workflow return values {/* #workflow-return-values */} Workflow return values must also be serializable. Returning results, returning errors, or throwing exceptions is fairly idiomatic in each language that is supported. However, Temporal APIs that must be used to get the result of a Workflow @@ -92,7 +91,7 @@ export async function example({ name, born }: ExampleParam): Promise { } ``` -## How to customize your Workflow Type {/* #workflow-type */} +## Customize Workflow Type {/* #workflow-type */} Workflows have a Type that are referred to as the Workflow name. @@ -112,7 +111,7 @@ export async function helloWorld(): Promise { ``` -## How to develop Workflow logic {/* #workflow-logic-requirements */} +## Workflow logic requirements {/* #workflow-logic-requirements */} Workflow logic is constrained by [deterministic execution requirements](/workflow-definition#deterministic-constraints). Each Temporal SDK provides a @@ -141,7 +140,7 @@ and [WeakRef](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/ The following sections describe the replay-safe APIs available in the sandbox. -#### Logging +### Logging Use [`log`](https://typescript.temporal.io/api/namespaces/workflow#log) from `@temporalio/workflow` instead of `console.log`. The SDK logger automatically suppresses messages during replay to avoid duplicates: @@ -156,7 +155,7 @@ export async function myWorkflow(name: string): Promise { For logger configuration, see [Observability: Log from a Workflow](/develop/typescript/platform/observability#logging). -#### Random numbers and UUIDs +### Random numbers and UUIDs `Math.random()` is replaced by a deterministic version in the sandbox, so you can use it directly. It produces the same sequence of values on replay. @@ -171,7 +170,7 @@ const id = uuid4(); Third-party UUID libraries that rely on `Math.random()` (such as the `uuid` package) are also safe, but the built-in avoids the dependency. -#### Current time +### Current time `Date.now()` and `new Date()` are replaced by deterministic versions that return the time of the last Workflow Task completion. The value only advances when you `await` something (like `sleep()`): @@ -190,7 +189,7 @@ for (let x = 0; x < 10; ++x) { } ``` -#### Detecting replay (advanced) +### Detecting replay (advanced) Use [`workflowInfo().unsafe.isReplaying`](https://typescript.temporal.io/api/interfaces/workflow.UnsafeWorkflowInfo#isreplaying) to guard code that should only run on the first execution, such as emitting metrics or sending external notifications from an [Interceptor](/develop/typescript/workers/interceptors). :::caution From 22eb0f0dd56c630281ab5d3ec65f2a46120ef41a Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Thu, 3 Sep 2026 23:12:35 +0000 Subject: [PATCH 2/2] Nest Rust workflow implementation headings Co-authored-by: jsundai <36107423+jsundai@users.noreply.github.com> --- docs/develop/rust/workflows/basics.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/develop/rust/workflows/basics.mdx b/docs/develop/rust/workflows/basics.mdx index a4cd3c01f4..664c64e125 100644 --- a/docs/develop/rust/workflows/basics.mdx +++ b/docs/develop/rust/workflows/basics.mdx @@ -48,11 +48,11 @@ impl GreetingWorkflow { The `#[workflow]` macro marks the struct as a Workflow. The `#[workflow_methods]` macro is applied to the `impl` block containing the Workflow methods. -## Workflow struct {/* #workflow-struct */} +### Workflow struct {/* #workflow-struct */} The Workflow struct holds the state of your Workflow Execution. This state is persisted and recovered during replays. All fields in a Workflow struct should be serializable. -## Workflow initialization {/* #init-method */} +### Workflow initialization {/* #init-method */} The `#[init]` method is optional and is called when the Workflow first starts. It receives the initial Workflow input parameters and initializes the Workflow struct: