From 8e359f3f49c168bf7cc7ef9fe49c4d80507367be Mon Sep 17 00:00:00 2001 From: Ben Echols Date: Fri, 27 Feb 2026 09:00:30 -0800 Subject: [PATCH 1/2] Fix typos in .NET, PHP, Ruby SDK and top-level develop documentation Co-Authored-By: Claude Opus 4.6 (1M context) --- docs/develop/activity-retry-simulator.mdx | 2 +- docs/develop/dotnet/core-application.mdx | 6 +++--- docs/develop/dotnet/debugging.mdx | 6 +++--- docs/develop/dotnet/index.mdx | 4 ++-- docs/develop/dotnet/message-passing.mdx | 4 ++-- docs/develop/dotnet/observability.mdx | 2 +- docs/develop/dotnet/schedules.mdx | 4 ++-- docs/develop/dotnet/temporal-client.mdx | 2 +- docs/develop/dotnet/temporal-nexus.mdx | 2 +- docs/develop/php/asynchronous-activity-completion.mdx | 4 ++-- docs/develop/php/core-application.mdx | 10 +++++----- docs/develop/php/debugging.mdx | 2 +- docs/develop/php/enriching-ui.mdx | 2 +- docs/develop/php/message-passing.mdx | 6 +++--- docs/develop/php/temporal-clients.mdx | 2 +- docs/develop/plugins-guide.mdx | 2 +- docs/develop/ruby/failure-detection.mdx | 2 -- docs/develop/ruby/index.mdx | 4 ++-- docs/develop/ruby/message-passing.mdx | 6 +++--- docs/develop/ruby/temporal-client.mdx | 3 --- docs/develop/ruby/versioning.mdx | 2 +- 21 files changed, 36 insertions(+), 41 deletions(-) diff --git a/docs/develop/activity-retry-simulator.mdx b/docs/develop/activity-retry-simulator.mdx index 4e88d3c490..08338a8108 100644 --- a/docs/develop/activity-retry-simulator.mdx +++ b/docs/develop/activity-retry-simulator.mdx @@ -8,7 +8,7 @@ tags: --- Use this tool to visualize total Activity Execution times and experiment with different Activity timeouts and Retry Policies. -For a list of Activity Task Execution times, use [this calculator](https://temporal-time.netlify.app/?initialInterval=1&maxInterval=100&maxReties=10&backoffCoeificent=2). +For a list of Activity Task Execution times, use [this calculator](https://temporal-time.netlify.app/?initialInterval=1&maxInterval=100&maxReties=10&backoffCoefficient=2). The simulator is based on a common Activity use-case, which is to call a third party HTTP API and return the results. See the example code snippets below. diff --git a/docs/develop/dotnet/core-application.mdx b/docs/develop/dotnet/core-application.mdx index 9643bddfc1..5e7b22f0b9 100644 --- a/docs/develop/dotnet/core-application.mdx +++ b/docs/develop/dotnet/core-application.mdx @@ -114,7 +114,7 @@ Here are some known gotchas to avoid with .NET tasks inside of Workflows: In order to help catch wrong scheduler use, by default the Temporal .NET SDK adds an event source listener for info-level task events. While this technically receives events from all uses of tasks in the process, we make sure to ignore anything that is not running in a Workflow in a high performant way (basically one thread local check). -For code that does run in a Workflow and accidentally starts a task in another scheduler, an `InvalidWorkflowOperationException` will be thrown which "pauses" the Workflow (fails the Workflow Rask which continually retries until the code is fixed). +For code that does run in a Workflow and accidentally starts a task in another scheduler, an `InvalidWorkflowOperationException` will be thrown which "pauses" the Workflow (fails the Workflow Task which continually retries until the code is fixed). This is unfortunately a runtime-only check, but can help catch mistakes early. If this needs to be turned off for any reason, set `DisableWorkflowTracingEventListener` to `true` in Worker options. In the near future for modern .NET versions we hope to use the @@ -247,7 +247,7 @@ Technically this can be multiple parameters, but Temporal strongly encourages a Calls to spawn [Activity Executions](/activity-execution) are written within a [Workflow Definition](/workflow-definition). The call to spawn an Activity Execution generates the [ScheduleActivityTask](/references/commands#scheduleactivitytask) Command. -This results in the set of three [Activity Task](/tasks#activity-task) related Events ([ActivityTaskScheduled](/references/events#activitytaskscheduled), [ActivityTaskStarted](/references/events#activitytaskstarted), and ActivityTask[Closed])in your Workflow Execution Event History. +This results in the set of three [Activity Task](/tasks#activity-task) related Events ([ActivityTaskScheduled](/references/events#activitytaskscheduled), [ActivityTaskStarted](/references/events#activitytaskstarted), and ActivityTask[Closed]) in your Workflow Execution Event History. A single instance of the Activities implementation is shared across multiple simultaneous Activity invocations. Activity implementation code should be _idempotent_. @@ -285,7 +285,7 @@ These values are set in the Activity Options. **How to get the results of an Activity Execution using the Temporal .NET SDK** -The Activity result is the returned in the task from the `ExecuteActivityAsync` call. +The Activity result is returned in the task from the `ExecuteActivityAsync` call. ## Run Worker Process diff --git a/docs/develop/dotnet/debugging.mdx b/docs/develop/dotnet/debugging.mdx index 8ad7bf8198..0d338af236 100644 --- a/docs/develop/dotnet/debugging.mdx +++ b/docs/develop/dotnet/debugging.mdx @@ -20,7 +20,7 @@ tags: This page shows how to do the following: - [Debug in a development environment](#debug-in-a-development-environment) -- [Debug in a development production](#debug-in-a-development-production) +- [Debug in a production environment](#debug-in-a-development-production) ### Debug in a development environment {#debug-in-a-development-environment} @@ -30,9 +30,9 @@ In developing Workflows, you can use the normal development tools of logging and In addition to the normal development tools of logging and a debugger, you can also see what’s happening in your Workflow by using the [Web UI](/web-ui) or [Temporal CLI](/cli). The Web UI provides insight into your Workflows, making it easier to identify issues and monitor the state of your Workflows in real time. -### Debug in a development production {#debug-in-a-development-production} +### Debug in a production environment {#debug-in-a-development-production} -**How to debug in a development production using the Temporal .NET SDK** +**How to debug in a production environment using the Temporal .NET SDK** You can debug production Workflows using: diff --git a/docs/develop/dotnet/index.mdx b/docs/develop/dotnet/index.mdx index c208c4e306..463fa81030 100644 --- a/docs/develop/dotnet/index.mdx +++ b/docs/develop/dotnet/index.mdx @@ -159,13 +159,13 @@ Configure and use the Temporal Observability APIs. - [Emit Metrics](/develop/dotnet/observability#metrics): Each Temporal SDK is capable of emitting an optional set of metrics from either the Client or the Worker process. -- [Set up Tracing](/develop/dotnet/observability#tracing): Explains how the Go SDK supports tracing and custom context +- [Set up Tracing](/develop/dotnet/observability#tracing): Explains how the .NET SDK supports tracing and custom context propagation. - [Log from a Workflow](/develop/dotnet/observability#logging): Send logs and errors to a logging service, so that when things go wrong, you can see what happened. - [Use Visibility APIs](/develop/dotnet/observability#visibility): The term Visibility, within the Temporal Platform, refers to the subsystems and APIs that enable an operator to view Workflow Executions that currently exist within a - Terminal Service. + Temporal Service. ## [Debugging](/develop/dotnet/debugging) diff --git a/docs/develop/dotnet/message-passing.mdx b/docs/develop/dotnet/message-passing.mdx index d95a6756c8..e8c7a44c3e 100644 --- a/docs/develop/dotnet/message-passing.mdx +++ b/docs/develop/dotnet/message-passing.mdx @@ -320,7 +320,7 @@ To send an Update to a Workflow Execution, you can: wf => wf.SetCurrentLanguageAsync(GreetingWorkflow.Language.Chinese)); ``` -- 2. Use `StartUpdateAsync` to receive a handle as soon as the Update is accepted. +2. Use `StartUpdateAsync` to receive a handle as soon as the Update is accepted. It returns an `UpdateHandle` - Use this `UpdateHandle` later to fetch your results. @@ -714,7 +714,7 @@ When working with Updates, you may encounter these errors: - **No Workflow Workers are polling the Task Queue**: Your request will be retried by the SDK Client indefinitely. Use a `CancellationToken` in your [RPC options](https://dotnet.temporal.io/api/Temporalio.Client.WorkflowUpdateOptions.html#Temporalio_Client_WorkflowUpdateOptions_Rpc) to cancel the Update. - This raises a [Temporalio.Exceptions.WorkflowUpdateRpcTimeoutOrCanceledException](https://dotnet.temporal.io/api/Temporalio.Exceptions.WorkflowUpdateRpcTimeoutOrCanceledException.html) exception . + This raises a [Temporalio.Exceptions.WorkflowUpdateRpcTimeoutOrCanceledException](https://dotnet.temporal.io/api/Temporalio.Exceptions.WorkflowUpdateRpcTimeoutOrCanceledException.html) exception. - **Update failed**: You'll receive a [`Temporalio.Exceptions.WorkflowUpdateFailedException`](https://dotnet.temporal.io/api/Temporalio.Exceptions.WorkflowUpdateFailedException.html) exception. There are two ways this can happen: diff --git a/docs/develop/dotnet/observability.mdx b/docs/develop/dotnet/observability.mdx index 042bb2961c..d10833cd7d 100644 --- a/docs/develop/dotnet/observability.mdx +++ b/docs/develop/dotnet/observability.mdx @@ -241,5 +241,5 @@ var myTextAttributeKey = SearchAttributeKey.CreateText("MyTextAttribute"); // Add/Update the keyword one and remove the text one Workflow.UpsertTypedSearchAttributes( myKeywordAttributeKey.ValueSet("SomeKeywordValue"), - myTextAttrbiuteKey.ValueUnset()); + myTextAttributeKey.ValueUnset()); ``` diff --git a/docs/develop/dotnet/schedules.mdx b/docs/develop/dotnet/schedules.mdx index ce206e1122..d21c747e02 100644 --- a/docs/develop/dotnet/schedules.mdx +++ b/docs/develop/dotnet/schedules.mdx @@ -31,9 +31,9 @@ This page shows how to do the following: **How to Schedule a Workflow using the Temporal .NET SDK** -Scheduling Workflows is a crucial aspect of any automation process, especially when dealing with time-sensitive tasks. By scheduling a Workflow, you can automate repetitive tasks, reduce the need for manual intervention, and ensure timely execution of your business processes +Scheduling Workflows is a crucial aspect of any automation process, especially when dealing with time-sensitive tasks. By scheduling a Workflow, you can automate repetitive tasks, reduce the need for manual intervention, and ensure timely execution of your business processes. -Use any of the following action to help Schedule a Workflow Execution and take control over your automation process. +Use any of the following actions to help Schedule a Workflow Execution and take control over your automation process. ### Create a Scheduled Workflow {#create-a-workflow} diff --git a/docs/develop/dotnet/temporal-client.mdx b/docs/develop/dotnet/temporal-client.mdx index 3d36a510cf..93a7b85f9c 100644 --- a/docs/develop/dotnet/temporal-client.mdx +++ b/docs/develop/dotnet/temporal-client.mdx @@ -438,7 +438,7 @@ public static class LoadFromFile -You can also provide connections options in your Go code directly. To create an initial connection, provide the +You can also provide connections options in your .NET code directly. To create an initial connection, provide the Namespace and API key values to the ` TemporalClient.ConnectAsync` method. ```csharp diff --git a/docs/develop/dotnet/temporal-nexus.mdx b/docs/develop/dotnet/temporal-nexus.mdx index f0ea419372..c4a6c9c66d 100644 --- a/docs/develop/dotnet/temporal-nexus.mdx +++ b/docs/develop/dotnet/temporal-nexus.mdx @@ -396,7 +396,7 @@ See the [Nexus cancellation sample](https://github.com/temporalio/samples-dotnet ## Make Nexus calls across Namespaces in Temporal Cloud {#nexus-calls-across-namespaces-temporal-cloud} -This section assumes you are already familiar with how to connect a Worker to Temporal Cloud. +This section assumes you are already familiar with how to connect a Worker to Temporal Cloud. The `tcld` CLI is used to create Namespaces and the Nexus Endpoint, and mTLS client certificates will be used to securely connect the caller and handler Workers to their respective Temporal Cloud Namespaces. ### Install the latest `tcld` CLI and generate certificates diff --git a/docs/develop/php/asynchronous-activity-completion.mdx b/docs/develop/php/asynchronous-activity-completion.mdx index 33352089f3..af4c72e53b 100644 --- a/docs/develop/php/asynchronous-activity-completion.mdx +++ b/docs/develop/php/asynchronous-activity-completion.mdx @@ -32,8 +32,8 @@ Calling `yield` on promise blocks until a result is available. > Activity promise also exposes `then` method to construct promise chains. > Read more about Promises [here](https://github.com/reactphp/promise). -Alternatively you can explicitly wrap your code (including `yield` constucts) using `Workflow::async` which will execute nested code in parallel with main Workflow code. -Call `yeild` on Promise returned by `Workflow::async` to merge execution result back to primary Workflow method. +Alternatively you can explicitly wrap your code (including `yield` constructs) using `Workflow::async` which will execute nested code in parallel with main Workflow code. +Call `yield` on Promise returned by `Workflow::async` to merge execution result back to primary Workflow method. ```php public function greet(string $name): \Generator diff --git a/docs/develop/php/core-application.mdx b/docs/develop/php/core-application.mdx index 3f17113e5d..85e49b2ffd 100644 --- a/docs/develop/php/core-application.mdx +++ b/docs/develop/php/core-application.mdx @@ -253,7 +253,7 @@ The `#[ActivityInterface("file_activities.")]` is an attribute that tells the PH Calls to spawn [Activity Executions](/activity-execution) are written within a [Workflow Definition](/workflow-definition). The call to spawn an Activity Execution generates the [ScheduleActivityTask](/references/commands#scheduleactivitytask) Command. -This results in the set of three [Activity Task](/tasks#activity-task) related Events ([ActivityTaskScheduled](/references/events#activitytaskscheduled), [ActivityTaskStarted](/references/events#activitytaskstarted), and ActivityTask[Closed])in your Workflow Execution Event History. +This results in the set of three [Activity Task](/tasks#activity-task) related Events ([ActivityTaskScheduled](/references/events#activitytaskscheduled), [ActivityTaskStarted](/references/events#activitytaskstarted), and ActivityTask[Closed]) in your Workflow Execution Event History. A single instance of the Activities implementation is shared across multiple simultaneous Activity invocations. Activity implementation code should be _idempotent_. @@ -393,9 +393,9 @@ A Worker Entity contains a Workflow Worker and/or an Activity Worker, which make The [RoadRunner application server](https://roadrunner.dev/) will launch multiple Temporal PHP Worker processes based on provided `.rr.yaml` configuration. Each Worker might connect to one or multiple Task Queues. -Worker poll _Temporal service_ for tasks, performs those tasks, and communicates task execution results back to the _Temporal service_. +Workers poll the _Temporal Service_ for tasks, performs those tasks, and communicates task execution results back to the _Temporal Service_. -Worker code are developed, deployed, and operated by Temporal customers. +Worker code is developed, deployed, and operated by Temporal customers. To create a worker use `Temporal\WorkerFactory`: ```php @@ -435,7 +435,7 @@ You can configure task queue name using first argument of `WorkerFactory`->`newW $worker = $factory->newWorker('your-task-queue'); ``` -As mentioned precedingyou can create as many Task Queue connections inside a single Worker Process as you need. +As mentioned preceding, you can create as many Task Queue connections inside a single Worker Process as you need. To configure additional WorkerOptions use `Temporal\Worker\WorkerOptions`: @@ -509,5 +509,5 @@ If you want to clean up some resources after activity is done, you may register after each activity invocation: ```php -$worker->registerActivityFinalizer(fn() => $kernel->showtdown()); +$worker->registerActivityFinalizer(fn() => $kernel->shutdown()); ``` diff --git a/docs/develop/php/debugging.mdx b/docs/develop/php/debugging.mdx index 6dd61ee2e3..3b5a54b673 100644 --- a/docs/develop/php/debugging.mdx +++ b/docs/develop/php/debugging.mdx @@ -19,7 +19,7 @@ tags: In addition to the normal development tools of logging and a debugger, you can also see what's happening in your Workflow by using the [Web UI](/web-ui) or [Temporal CLI](/cli). -### How to debug in a development production {#debug-in-a-development-production} +### How to debug in a production environment {#debug-in-a-development-production} You can debug production Workflows using: diff --git a/docs/develop/php/enriching-ui.mdx b/docs/develop/php/enriching-ui.mdx index a9241916f2..95e4da5f64 100644 --- a/docs/develop/php/enriching-ui.mdx +++ b/docs/develop/php/enriching-ui.mdx @@ -136,7 +136,7 @@ All Workflow details support standard Markdown formatting (excluding images, HTM ### Event History -Individual events in the Workflow's Event Gistory display their associated summaries when available. +Individual events in the Workflow's Event History display their associated summaries when available. Workflow, Activity and Timer summaries appear in purple text next to their corresponding Events, providing immediate context without requiring you to expand the event details. When you do expand an Event, the summary is also prominently displayed in the detailed view. diff --git a/docs/develop/php/message-passing.mdx b/docs/develop/php/message-passing.mdx index 30644807af..67048be365 100644 --- a/docs/develop/php/message-passing.mdx +++ b/docs/develop/php/message-passing.mdx @@ -81,7 +81,7 @@ interface FileProcessingWorkflow Note that name parameter of Workflow method attributes can be used to specify name of Workflow, Signal and Query types. If name is not specified the short name of the Workflow interface is used. -In the precedingcode the `#[WorkflowMethod(name)]` is not specified, thus the Workflow Type defaults to `"FileProcessingWorkflow"`. +In the preceding code the `#[WorkflowMethod(name)]` is not specified, thus the Workflow Type defaults to `"FileProcessingWorkflow"`. ### How to handle a Signal {#handle-signal} @@ -253,7 +253,7 @@ interface FileProcessingWorkflow Note that name parameter of Workflow method attributes can be used to specify name of Workflow, Signal and Query types. If name is not specified the short name of the Workflow interface is used. -In the precedingcode the `#[WorkflowMethod(name)]` is not specified, thus the Workflow Type defaults to `"FileProcessingWorkflow"`. +In the preceding code the `#[WorkflowMethod(name)]` is not specified, thus the Workflow Type defaults to `"FileProcessingWorkflow"`. ### How to handle a Query {#handle-query} @@ -773,7 +773,7 @@ When sending a Signal, Update, or Query to a Workflow, your Client might encount You'll receive a [`ServiceClientException`](https://php.temporal.io/classes/Temporal-Exception-Client-ServiceClientException.html) in case of a server connection error. [How to configure RPC Retry Policy](/develop/php/temporal-client#configure-rpc-retry-policy) -- **RPC timout**: +- **RPC timeout**: You'll receive a [`TimeoutException`](https://php.temporal.io/classes/Temporal-Exception-Client-TimeoutException.html) in case of an RPC timeout. [How to configure RPC timeout](/develop/php/temporal-client#configure-rpc-timeout) diff --git a/docs/develop/php/temporal-clients.mdx b/docs/develop/php/temporal-clients.mdx index 2a7d54e18e..42067fa261 100644 --- a/docs/develop/php/temporal-clients.mdx +++ b/docs/develop/php/temporal-clients.mdx @@ -17,7 +17,7 @@ description: Connect a Temporal Client to a Temporal Service and start Workflow This guide introduces Temporal Clients. It explains the role and use of Clients and shows you how to configure your PHP Client code to connect to the Temporal Service. -The pages shows how to do the following: +This page shows how to do the following: - [Connect to a local development Temporal Service](#connect-to-a-dev-cluster) - [Connect to Temporal Cloud](#connect-to-temporal-cloud) diff --git a/docs/develop/plugins-guide.mdx b/docs/develop/plugins-guide.mdx index 0f51224a81..dc0240bebf 100644 --- a/docs/develop/plugins-guide.mdx +++ b/docs/develop/plugins-guide.mdx @@ -345,7 +345,7 @@ The Replayer allows Workflow authors to validate that their Workflows will work The Replayer runs on a Workflow History created by a previous Workflow run. Suppose something in the Workflow or underlying code has changed in a way which could potentially cause a non-determinism error. In that case, the Replayer will notice the change in the way it runs compared to the history provided. -The Replayer is typically configured identically to the Worker and client. Ff you’re using `SimplePlugin`, this is already handled for you. +The Replayer is typically configured identically to the Worker and client. If you’re using `SimplePlugin`, this is already handled for you. If you need to do something custom for the Replayer, you can configure it directly. Here's an example of how to do that with Python: diff --git a/docs/develop/ruby/failure-detection.mdx b/docs/develop/ruby/failure-detection.mdx index 6e6c9af4d7..b208c15dce 100644 --- a/docs/develop/ruby/failure-detection.mdx +++ b/docs/develop/ruby/failure-detection.mdx @@ -132,8 +132,6 @@ result = my_client.execute_workflow( A Retry Policy can work in cooperation with the timeouts to provide fine controls to optimize the execution experience. Use a [Retry Policy](/encyclopedia/retry-policies) to automatically retry Workflow Executions on failure. -Workflow Executions do not retry by default. - Workflow Executions do not retry by default, and Retry Policies should be used with Workflow Executions only in certain situations. The `retry_policy` can be set when calling `start_workflow` or `execute_workflow`. diff --git a/docs/develop/ruby/index.mdx b/docs/develop/ruby/index.mdx index 19a4716122..e3c3bf24a0 100644 --- a/docs/develop/ruby/index.mdx +++ b/docs/develop/ruby/index.mdx @@ -160,13 +160,13 @@ Configure and use the Temporal Observability APIs. - [Emit Metrics](/develop/ruby/observability#metrics): Each Temporal SDK is capable of emitting an optional set of metrics from either the Client or the Worker process. -- [Set up Tracing](/develop/ruby/observability#tracing): Explains how the Go SDK supports tracing and custom context +- [Set up Tracing](/develop/ruby/observability#tracing): Explains how the Ruby SDK supports tracing and custom context propagation. - [Log from a Workflow](/develop/ruby/observability#logging): Send logs and errors to a logging service, so that when things go wrong, you can see what happened. - [Use Visibility APIs](/develop/ruby/observability#visibility): The term Visibility, within the Temporal Platform, refers to the subsystems and APIs that enable an operator to view Workflow Executions that currently exist within a - Terminal Service. + Temporal Service. ## [Debugging](/develop/ruby/debugging) diff --git a/docs/develop/ruby/message-passing.mdx b/docs/develop/ruby/message-passing.mdx index 7db6e6c4eb..27f8ae5bd0 100644 --- a/docs/develop/ruby/message-passing.mdx +++ b/docs/develop/ruby/message-passing.mdx @@ -291,7 +291,7 @@ To send an Update to a Workflow Execution, you can: prev_language = handle.execute_update(MessagePassingSimple::GreetingWorkflow.set_language, :chinese) ``` -- 2. Use `start_update` to receive a handle as soon as the Update is accepted. +2. Use `start_update` to receive a handle as soon as the Update is accepted. It returns a `WorkflowUpdateHandle` - Use this `WorkflowUpdateHandle` later to fetch your results. @@ -622,7 +622,7 @@ When working with Updates, you may encounter these errors: - **No Workflow Workers are polling the Task Queue**: Your request will be retried by the SDK Client indefinitely. Use a `Cancellation` in your [RPC options](https://ruby.temporal.io/Temporalio/Client/RPCOptions.html) to cancel the Update. - This raises a [WorkflowUpdateRPCTimeoutOrCanceledError](https://ruby.temporal.io/Temporalio/Error/WorkflowUpdateRPCTimeoutOrCanceledError.html) exception . + This raises a [WorkflowUpdateRPCTimeoutOrCanceledError](https://ruby.temporal.io/Temporalio/Error/WorkflowUpdateRPCTimeoutOrCanceledError.html) exception. - **Update failed**: You'll receive a [`WorkflowUpdateFailedError`](https://ruby.temporal.io/Temporalio/Error/WorkflowUpdateFailedError.html) exception. There are two ways this can happen: @@ -734,7 +734,7 @@ A Dynamic Update in Temporal is an Update that is invoked dynamically at runtime An Update can be made dynamic by setting `dynamic` to `true` on the `workflow_update` class method. Only one Dynamic Update can be present on a Workflow. -The Query Handler parameters must accept a string name as the first parameter. Often users set `raw_args` to `true` and set the second parameter as `*args` which will be an array of `Temporalio::Converters::RawValue`. +The Update Handler parameters must accept a string name as the first parameter. Often users set `raw_args` to `true` and set the second parameter as `*args` which will be an array of `Temporalio::Converters::RawValue`. The [Temporalio::Workflow.payload_converter](https://ruby.temporal.io/Temporalio/Workflow.html#payload_converter-class_method) property is used to convert the raw value instances to proper types. ```ruby diff --git a/docs/develop/ruby/temporal-client.mdx b/docs/develop/ruby/temporal-client.mdx index e97ac21a5e..774f55f42c 100644 --- a/docs/develop/ruby/temporal-client.mdx +++ b/docs/develop/ruby/temporal-client.mdx @@ -256,9 +256,6 @@ overrides the option set in the configuration file. 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 -connect to Temporal Cloud via an API key: - ```toml # Cloud profile for Temporal Cloud [profile.staging] diff --git a/docs/develop/ruby/versioning.mdx b/docs/develop/ruby/versioning.mdx index 3001ef6738..62bfbcb92a 100644 --- a/docs/develop/ruby/versioning.mdx +++ b/docs/develop/ruby/versioning.mdx @@ -83,7 +83,7 @@ Patching is a three-step process: 1. Patch in any new, updated code using the `patched()` function. Run the new patched code alongside old code. 2. Remove old code and use `deprecate_patch()` to mark a particular patch as deprecated. -3. Once there are no longer any open Worklow Executions of the previous version of the code, remove `deprecatePatch()`. +3. Once there are no longer any open Workflow Executions of the previous version of the code, remove `deprecate_patch()`. Let's walk through this process in sequence. ### Patching in new code From d10c60807c225423099065c4e262cc0c4c964a8a Mon Sep 17 00:00:00 2001 From: Ben Echols Date: Fri, 27 Feb 2026 10:32:24 -0800 Subject: [PATCH 2/2] Update docs/develop/php/core-application.mdx --- docs/develop/php/core-application.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/develop/php/core-application.mdx b/docs/develop/php/core-application.mdx index 85e49b2ffd..0a5b5fdcd5 100644 --- a/docs/develop/php/core-application.mdx +++ b/docs/develop/php/core-application.mdx @@ -393,7 +393,7 @@ A Worker Entity contains a Workflow Worker and/or an Activity Worker, which make The [RoadRunner application server](https://roadrunner.dev/) will launch multiple Temporal PHP Worker processes based on provided `.rr.yaml` configuration. Each Worker might connect to one or multiple Task Queues. -Workers poll the _Temporal Service_ for tasks, performs those tasks, and communicates task execution results back to the _Temporal Service_. +Workers poll the _Temporal Service_ for tasks, perform those tasks, and communicate task execution results back to the _Temporal Service_. Worker code is developed, deployed, and operated by Temporal customers. To create a worker use `Temporal\WorkerFactory`: