From 407c3ac8bf897d7208c4b3df7e854fbcae86f04a Mon Sep 17 00:00:00 2001 From: Ben Echols Date: Fri, 27 Feb 2026 09:00:31 -0800 Subject: [PATCH] Fix typos in encyclopedia documentation Co-Authored-By: Claude Opus 4.6 (1M context) --- docs/encyclopedia/activities/activities.mdx | 2 +- docs/encyclopedia/activities/activity-definition.mdx | 2 +- .../data-conversion/remote-data-encoding.mdx | 2 +- docs/encyclopedia/detecting-activity-failures.mdx | 2 +- docs/encyclopedia/event-history/dotnet.mdx | 2 +- docs/encyclopedia/event-history/go.mdx | 2 +- docs/encyclopedia/event-history/java.mdx | 2 +- docs/encyclopedia/event-history/python.mdx | 2 +- docs/encyclopedia/event-history/typescript.mdx | 2 +- docs/encyclopedia/nexus-error-handling.mdx | 2 +- docs/encyclopedia/nexus-operations.mdx | 2 +- docs/encyclopedia/nexus-security.mdx | 2 +- docs/encyclopedia/nexus-use-cases.mdx | 4 ++-- docs/encyclopedia/temporal-sdks.mdx | 10 +++++----- docs/encyclopedia/visibility/search-attributes.mdx | 2 +- docs/encyclopedia/worker-versioning-legacy.mdx | 6 +++--- docs/encyclopedia/workers/tasks.mdx | 2 +- docs/encyclopedia/workers/worker-versioning.mdx | 2 +- docs/encyclopedia/workflow/schedule.mdx | 2 +- docs/encyclopedia/workflow/workflow-definition.mdx | 2 +- 20 files changed, 27 insertions(+), 27 deletions(-) diff --git a/docs/encyclopedia/activities/activities.mdx b/docs/encyclopedia/activities/activities.mdx index b3dd08b612..276cf24e54 100644 --- a/docs/encyclopedia/activities/activities.mdx +++ b/docs/encyclopedia/activities/activities.mdx @@ -29,7 +29,7 @@ Activities are the most common Temporal primitive and encompass small units of w - Single write operations, like updating user information or submitting a credit card payment - Batches of similar writes, like creating multiple orders or sending multiple messages -- One or more read operations followed by a write operation, like checking an product status and user address before updating an order status +- One or more read operations followed by a write operation, like checking a product status and user address before updating an order status - A read that should be memoized, like an LLM call, a large download, or a slow-polling read Larger pieces of functionality should be broken up into multiple activities. This makes it easier to do failure recovery, have short timeouts, and be idempotent. diff --git a/docs/encyclopedia/activities/activity-definition.mdx b/docs/encyclopedia/activities/activity-definition.mdx index 5acbfba998..4f5d141f0f 100644 --- a/docs/encyclopedia/activities/activity-definition.mdx +++ b/docs/encyclopedia/activities/activity-definition.mdx @@ -150,7 +150,7 @@ Activity Types are scoped through Task Queues. ## Best practices for defining Activities -Here are some best practices you can use when you are creating an Activities for your Workflow: +Here are some best practices you can use when you are creating Activities for your Workflow: - Activity arguments and return values should be serializable. - Activities that perform writes should be idempotent. diff --git a/docs/encyclopedia/data-conversion/remote-data-encoding.mdx b/docs/encyclopedia/data-conversion/remote-data-encoding.mdx index d5b803cb5f..5c2fee8c84 100644 --- a/docs/encyclopedia/data-conversion/remote-data-encoding.mdx +++ b/docs/encyclopedia/data-conversion/remote-data-encoding.mdx @@ -36,7 +36,7 @@ The Temporal CLI and the Web UI in turn provide built-in hooks to call the Codec ### Encoding data on the Web UI and CLI You can perform some operations on your Workflow Execution using the Temporal CLI and the Web UI. -For example. you can start or signal an active Workflow Execution from the Temporal CLI or cancel a Workflow Execution from the Web UI, which might require inputs that contain sensitive data. +For example, you can start or signal an active Workflow Execution from the Temporal CLI or cancel a Workflow Execution from the Web UI, which might require inputs that contain sensitive data. To encode this data, specify your [Codec Server endpoints](/codec-server) with the `codec-endpoint` parameter in [the Temporal CLI](/cli) and configure your Web UI to use the Codec Server endpoints. diff --git a/docs/encyclopedia/detecting-activity-failures.mdx b/docs/encyclopedia/detecting-activity-failures.mdx index 9a2355d719..798e4b2ea7 100644 --- a/docs/encyclopedia/detecting-activity-failures.mdx +++ b/docs/encyclopedia/detecting-activity-failures.mdx @@ -228,7 +228,7 @@ Heartbeating is best thought about not in terms of time, but in terms of "How do For short-term operations, progress updates are not a requirement. However, checking the progress and status of Activity Executions that run over long periods is almost always useful. -Consider the following when setting Activity Hearbeats: +Consider the following when setting Activity Heartbeats: - Your underlying task must be able to report definite progress. Note that your Workflow cannot read this progress information while the Activity is still executing (or it would have to store it in Event History). diff --git a/docs/encyclopedia/event-history/dotnet.mdx b/docs/encyclopedia/event-history/dotnet.mdx index e12b032392..1561abb002 100644 --- a/docs/encyclopedia/event-history/dotnet.mdx +++ b/docs/encyclopedia/event-history/dotnet.mdx @@ -325,4 +325,4 @@ Remember that pretty much anything that interacts with the external world is inh **Good news**: Your Temporal application can absolutely handle all of these operations. While your Workflow must be deterministic, your application absolutely can handle any type of non-deterministic operation, including those listed above. This gives you the best of both worlds—the crash-proof reliability of a Workflow and the resiliency of Activities -with have built-in support for retries. +which have built-in support for retries. diff --git a/docs/encyclopedia/event-history/go.mdx b/docs/encyclopedia/event-history/go.mdx index 9ea1a56deb..6fd9d950ff 100644 --- a/docs/encyclopedia/event-history/go.mdx +++ b/docs/encyclopedia/event-history/go.mdx @@ -338,4 +338,4 @@ Remember that pretty much anything that interacts with the external world is inh **Good news**: Your Temporal application can absolutely handle all of these operations. While your Workflow must be deterministic, your application absolutely can handle any type of non-deterministic operation, including those listed above. This gives you the best of both worlds—the crash-proof reliability of a Workflow and the resiliency of Activities -with have built-in support for retries. +which have built-in support for retries. diff --git a/docs/encyclopedia/event-history/java.mdx b/docs/encyclopedia/event-history/java.mdx index 05d9d90452..5891061ccc 100644 --- a/docs/encyclopedia/event-history/java.mdx +++ b/docs/encyclopedia/event-history/java.mdx @@ -330,4 +330,4 @@ Remember that pretty much anything that interacts with the external world is inh **Good news**: Your Temporal application can absolutely handle all of these operations. While your Workflow must be deterministic, your application absolutely can handle any type of non-deterministic operation, including those listed above. This gives you the best of both worlds—the crash-proof reliability of a Workflow and the resiliency of Activities -with have built-in support for retries. +which have built-in support for retries. diff --git a/docs/encyclopedia/event-history/python.mdx b/docs/encyclopedia/event-history/python.mdx index 67d29144b0..08b305bf30 100644 --- a/docs/encyclopedia/event-history/python.mdx +++ b/docs/encyclopedia/event-history/python.mdx @@ -332,4 +332,4 @@ Remember that pretty much anything that interacts with the external world is inh **Good news**: Your Temporal application can absolutely handle all of these operations. While your Workflow must be deterministic, your application absolutely can handle any type of non-deterministic operation, including those listed above. This gives you the best of both worlds—the crash-proof reliability of a Workflow and the resiliency of Activities -with have built-in support for retries. +which have built-in support for retries. diff --git a/docs/encyclopedia/event-history/typescript.mdx b/docs/encyclopedia/event-history/typescript.mdx index e47d6f7a77..267ecfab5a 100644 --- a/docs/encyclopedia/event-history/typescript.mdx +++ b/docs/encyclopedia/event-history/typescript.mdx @@ -334,4 +334,4 @@ Remember that pretty much anything that interacts with the external world is inh **Good news**: Your Temporal application can absolutely handle all of these operations. While your Workflow must be deterministic, your application absolutely can handle any type of non-deterministic operation, including those listed above. This gives you the best of both worlds—the crash-proof reliability of a Workflow and the resiliency of Activities -with have built-in support for retries. +which have built-in support for retries. diff --git a/docs/encyclopedia/nexus-error-handling.mdx b/docs/encyclopedia/nexus-error-handling.mdx index 433ca60820..62463bc081 100644 --- a/docs/encyclopedia/nexus-error-handling.mdx +++ b/docs/encyclopedia/nexus-error-handling.mdx @@ -61,7 +61,7 @@ See [errors in Nexus Operations](/references/failures#errors-in-nexus-operations A Nexus Operation Failure is delivered to the Workflow Execution when a Nexus Operation fails. It contains information about the failure and the Nexus Operation Execution; for example, the Nexus Operation name and Nexus Operation token. -The reason for the failure is in the message and in the underlying cause is typically an Application Error or a Canceled Error. +The reason for the failure is in the message, and the underlying cause is typically an Application Error or a Canceled Error. :::tip RESOURCES diff --git a/docs/encyclopedia/nexus-operations.mdx b/docs/encyclopedia/nexus-operations.mdx index 4254432c3d..88a0d8800f 100644 --- a/docs/encyclopedia/nexus-operations.mdx +++ b/docs/encyclopedia/nexus-operations.mdx @@ -152,7 +152,7 @@ For example, this may be done by looking at the Request-Timeout header or hookin Temporal Nexus Operations are requested and processed using the Temporal queue-based Worker architecture. Workers interact with their Namespace gRPC endpoint as before. -Nexus Machinery on both sides handles the cross-namepace communication. +Nexus Machinery on both sides handles the cross-namespace communication. -This is when the SDK Worker Replays the Workflow code, uses the Event History as guidance on what to expect. If the Replay encounters an Event that doesn't match up with what is expected from the code, a [non-determinism](/references/errors#non-deterministic-error) error gets thrown. +This is when the SDK Worker Replays the Workflow code, using the Event History as guidance on what to expect. If the Replay encounters an Event that doesn't match up with what is expected from the code, a [non-determinism](/references/errors#non-deterministic-error) error gets thrown. If there is alignment, the Worker continues evaluating code. diff --git a/docs/encyclopedia/visibility/search-attributes.mdx b/docs/encyclopedia/visibility/search-attributes.mdx index 264027c984..b77d347534 100644 --- a/docs/encyclopedia/visibility/search-attributes.mdx +++ b/docs/encyclopedia/visibility/search-attributes.mdx @@ -201,7 +201,7 @@ Search Attributes available in your Visibility store can be used with Workflow E To actually have results from the use of a [List Filter](/list-filter), Search Attributes must be added to a Workflow Execution as metadata. - To create custom Search Attributes in your Visibility store, see [Create custom Search Attributes](/self-hosted-guide/visibility#create-custom-search-attributes). -- To remove a custom Search Attribute from the Visbility store, see [Remove custom Search Attributes](/self-hosted-guide/visibility#remove-custom-search-attributes). +- To remove a custom Search Attribute from the Visibility store, see [Remove custom Search Attributes](/self-hosted-guide/visibility#remove-custom-search-attributes). Removing custom Search Attributes is not supported on Temporal Cloud. - To rename a custom Search Attribute on Temporal Cloud, see [`tcld namespace search-attributes rename`](/cloud/tcld/namespace/#rename). diff --git a/docs/encyclopedia/worker-versioning-legacy.mdx b/docs/encyclopedia/worker-versioning-legacy.mdx index e2634ae569..5697307780 100644 --- a/docs/encyclopedia/worker-versioning-legacy.mdx +++ b/docs/encyclopedia/worker-versioning-legacy.mdx @@ -117,7 +117,7 @@ By default, both Task Queues and Workers are in an unversioned state. To use this feature, both the Task Queue and the Worker must be associated with Build IDs. If you run a Worker using versioning against a Task Queue that has not been set up to use versioning (or is missing that Worker's Build ID), it won't get any tasks. -Likewise, a unversioned Worker polling a Task Queue with versioning won't work either. +Likewise, an unversioned Worker polling a Task Queue with versioning won't work either. :::note Versions don't need to follow semver or any other semantic versioning scheme! @@ -140,7 +140,7 @@ If Workflows that don't have an assigned version are still running on the Task Q So ensure that such Workers are still operational if any Workflows were open when you added the first version. If you deployed any Workers with a _different_ version, those Workers receive no Tasks. -Now, imagine you need change the Workflow for some reason. +Now, imagine you need to change the Workflow for some reason. Add `2.0` to the sets as the new default: @@ -196,7 +196,7 @@ A request to change the sets can do one of the following: - Promote a version within an existing set to become the default for that set. - Promote a set to become the overall-default set. -You can't explicitly delete versions.This helps you avoid the situation in which Workflows accidentally become stuck with no means of making progress because the version they're associated with no longer exists. +You can't explicitly delete versions. This helps you avoid the situation in which Workflows accidentally become stuck with no means of making progress because the version they're associated with no longer exists. However, sometimes you might want to do this intentionally. If you _want_ to make sure that all Workflows currently being processed by, say, `2.0` stop (even if you don't yet have a new version ready), you can add a new version `2.1` to the sets marked as compatible with `2.0`. diff --git a/docs/encyclopedia/workers/tasks.mdx b/docs/encyclopedia/workers/tasks.mdx index f8ee42470c..b76c25f043 100644 --- a/docs/encyclopedia/workers/tasks.mdx +++ b/docs/encyclopedia/workers/tasks.mdx @@ -166,7 +166,7 @@ Temporal Worker triggers the registered Operation handler based on the Nexus tas ### What is a Nexus Task Execution? {#nexus-task-execution} A Nexus Task Execution occurs when a Worker uses the context provided from the Nexus Task and executes an action -associated with a Nexus Operation which commonly includes starting a Nexus Operation using it's Nexus Operation handler +associated with a Nexus Operation which commonly includes starting a Nexus Operation using its Nexus Operation handler plus many additional actions that may be performed on a Nexus Operation. The NexusOperationScheduled Event corresponds to when the Temporal Service records the Workflow's intent to schedule an diff --git a/docs/encyclopedia/workers/worker-versioning.mdx b/docs/encyclopedia/workers/worker-versioning.mdx index ab8dc94218..a12e6f6e80 100644 --- a/docs/encyclopedia/workers/worker-versioning.mdx +++ b/docs/encyclopedia/workers/worker-versioning.mdx @@ -51,7 +51,7 @@ A **Pinned** Workflow is guaranteed to complete on a single Worker Deployment Ve An **Auto-Upgrade** Workflow will move to the latest Worker Deployment Version automatically whenever you change the current version. Auto-upgrade Workflows are not restricted to a single Deployment Version and need to be kept replay-safe manually, i.e. with [patching](/workflow-definition#workflow-versioning). -### Actvity behavior across versions +### Activity behavior across versions There are a few scenarios to consider for your Activities when you're handling your Worker Deployment versions. diff --git a/docs/encyclopedia/workflow/schedule.mdx b/docs/encyclopedia/workflow/schedule.mdx index 8ba15af7f5..8f9837aa2d 100644 --- a/docs/encyclopedia/workflow/schedule.mdx +++ b/docs/encyclopedia/workflow/schedule.mdx @@ -204,7 +204,7 @@ It is important to note that the [status](/workflow-execution#workflow-execution A scheduled Workflow Execution may complete with a result up to the maximum blob size (2 MiB by default). However, due to internal limitations, results that are within 1 KiB of this limit cannot be passed to the next execution. So, for example, a Workflow Execution that returns a result of size 2,096,640 bytes (which is above 2MiB - 1KiB limit) -will be allowed to compete successfully, but that value will not be available as a last completion result. +will be allowed to complete successfully, but that value will not be available as a last completion result. This limitation may be lifted in the future. ::: diff --git a/docs/encyclopedia/workflow/workflow-definition.mdx b/docs/encyclopedia/workflow/workflow-definition.mdx index 51f31e89ad..281736a578 100644 --- a/docs/encyclopedia/workflow/workflow-definition.mdx +++ b/docs/encyclopedia/workflow/workflow-definition.mdx @@ -15,7 +15,7 @@ tags: import { CaptionedImage } from '@site/src/components'; -This pages covers the following: +This page covers the following: - [What is a Workflow Definition?](/workflow-definition) - [Determinism and constraints](#deterministic-constraints)