diff --git a/docs/best-practices/managing-namespace.mdx b/docs/best-practices/managing-namespace.mdx index 465b0868ba..e2a4631668 100644 --- a/docs/best-practices/managing-namespace.mdx +++ b/docs/best-practices/managing-namespace.mdx @@ -178,7 +178,7 @@ Use [Nexus](/nexus) where possible instead of sharing Temporal primitives across ## Production Safeguards -### Use an Authorizer (open source only) {#authorizer} +### Use an Authorizer (open source only) {/* #authorizer */} Use a custom [Authorizer](/self-hosted-guide/security#authorizer-plugin) on your Frontend Service to set restrictions on who can create, update, or deprecate Namespaces. @@ -186,15 +186,15 @@ If an Authorizer is not set, Temporal uses the `nopAuthority` authorizer that un On Temporal Cloud, [role-based access controls](/cloud/manage-access/roles-and-permissions#namespace-level-permissions) provide namespace-level authorization without custom configuration. -### Enable deletion protection (Temporal Cloud only) {#deletion-protection} +### Enable deletion protection (Temporal Cloud only) {/* #deletion-protection */} [Enable deletion protection](/cloud/namespaces#delete-protection) for production Namespaces to prevent accidental deletion. -### Enable High Availability (Temporal Cloud only) {#high-availability} +### Enable High Availability (Temporal Cloud only) {/* #high-availability */} For business-critical use cases with strict uptime requirements, enable [High Availability features](/cloud/high-availability) for a [99.99% contractual SLA](/cloud/high-availability#high-availability-features). -### Use Infrastructure as Code (Temporal Cloud only) {#terraform} +### Use Infrastructure as Code (Temporal Cloud only) {/* #terraform */} Use the [Temporal Cloud Terraform provider](/cloud/terraform-provider) to manage Namespaces. If Terraform isn't suitable, scripting against the [Cloud Ops API](/ops) or [tcld](/cloud/tcld) is a good alternative. @@ -209,7 +209,7 @@ This is separate from [Temporal Cloud deletion protection](/cloud/namespaces#del **Reference**: [Example Terraform configuration](https://github.com/kawofong/temporal-terraform) -## Tagging (Temporal Cloud only) {#tagging} +## Tagging (Temporal Cloud only) {/* #tagging */} [Tags](/cloud/namespaces#tag-a-namespace) are key-value metadata pairs that help organize, track, and manage Namespaces. diff --git a/docs/cli/activity.mdx b/docs/cli/activity.mdx index 7dd5b717a4..1512d372f5 100644 --- a/docs/cli/activity.mdx +++ b/docs/cli/activity.mdx @@ -253,7 +253,7 @@ is provided - it will stay paused. Either `--activity-id` (with `--workflow-id`) or `--query` must be specified. -### Resetting activities that heartbeat {#reset-heartbeats} +### Resetting activities that heartbeat {/* #reset-heartbeats */} Activities that heartbeat will receive a [Canceled failure](/references/failures#cancelled-failure) the next time they heartbeat after a reset. diff --git a/docs/cli/index.mdx b/docs/cli/index.mdx index 39bba67d13..c0d7fad885 100644 --- a/docs/cli/index.mdx +++ b/docs/cli/index.mdx @@ -31,7 +31,7 @@ commands. For details, see [CLI release notes](https://github.com/temporalio/cli ::: -## Install the Temporal CLI {#install} +## Install the Temporal CLI {/* #install */} The Temporal CLI is available on macOS, Windows, and Linux, or as a Docker image. @@ -107,7 +107,7 @@ docker run --rm -p 7233:7233 -p 8233:8233 temporalio/temporal server start-dev - ::: -## Start a Temporal development server {#start-dev-server} +## Start a Temporal development server {/* #start-dev-server */} To start a Temporal development server, run the following command: @@ -142,7 +142,7 @@ For the full list of development server options, use the `--help` flag: temporal server start-dev --help ``` -## Enable auto-completion {#enable-auto-completion} +## Enable auto-completion {/* #enable-auto-completion */} Enable auto-completion using the following commands. @@ -286,7 +286,7 @@ Do not confuse environment variables, set with your shell, with temporal env opt ::: -## Create and modify configuration files {#configuration-files} +## Create and modify configuration files {/* #configuration-files */} The Temporal CLI lets you create and modify TOML configuration files to store your environment variables and other settings. Refer to [Environment Configuration](../develop/environment-configuration#cli-integration) for more @@ -324,7 +324,7 @@ specific addresses or domains you wish to exclude from proxying. For more information, see [Proxy](https://github.com/grpc/grpc-go/blob/master/Documentation/proxy.md) in the gRPC documentation. -## Common CLI operations {#common-operations} +## Common CLI operations {/* #common-operations */} The following are some of the more common operations you can perform with the Temporal CLI. diff --git a/docs/cloud/audit-logs-aws.mdx b/docs/cloud/audit-logs-aws.mdx index eab90949ab..901268a00d 100644 --- a/docs/cloud/audit-logs-aws.mdx +++ b/docs/cloud/audit-logs-aws.mdx @@ -21,7 +21,7 @@ tags: - AWS --- -## Configure Audit Logs using AWS Kinesis {#configure-audit-log} +## Configure Audit Logs using AWS Kinesis {/* #configure-audit-log */} To set up Audit Logs, you must have an Amazon Web Services (AWS) account and set up Kinesis Data Streams. @@ -64,7 +64,7 @@ If you chose the **Manual** access method, continue with the following steps: To ensure that Audit Logs can flow into the Kinesis stream, you can use the **Verify** button to confirm it is set up correctly. This validates that Temporal can successfully write to your stream. If everything is configured correctly, you will see a `Success` status indicating Temporal has written to the kinesis stream. -## Consume an Audit Log {#consume-an-audit-log} +## Consume an Audit Log {/* #consume-an-audit-log */} **How to consume an Audit Log** diff --git a/docs/cloud/audit-logs.mdx b/docs/cloud/audit-logs.mdx index 71cb029b08..75db528ba6 100644 --- a/docs/cloud/audit-logs.mdx +++ b/docs/cloud/audit-logs.mdx @@ -33,7 +33,7 @@ Instead, explore the [Export](/cloud/export) feature, which does let you send cl ::: -## Which events are supported by Audit Logs? {#supported-events} +## Which events are supported by Audit Logs? {/* #supported-events */} - Account - `ChangeAccountPlanType`: Change Account Plan Type @@ -156,14 +156,14 @@ Temporal provides the caller IP address in that format to allow customers to ide ] ``` -## How to configure an Audit Log Integration {#configure-audit-logs} +## How to configure an Audit Log Integration {/* #configure-audit-logs */} Audit Logs can be configured in AWS Kinesis or GCP Pub/Sub. - [AWS Kinesis Instructions](/cloud/audit-logs-aws) - [GCP Pub/Sub Instructions](/cloud/audit-logs-gcp) -## How to troubleshoot Audit Log sink {#troubleshoot-audit-logs} +## How to troubleshoot Audit Log sink {/* #troubleshoot-audit-logs */} The Audit Logs page of the Temporal Cloud UI provides the current status of an Audit Log Integration. @@ -179,7 +179,7 @@ To retrieve logs up to the past 30 days, you will need to file a request. If you experience an issue with an Audit Log sink, we can provide the missing audit information. Open a support ticket to request assistance. -## How to delete an Audit Log sink {#delete-an-audit-log-sink} +## How to delete an Audit Log sink {/* #delete-an-audit-log-sink */} To delete an Audit Log sink, follow these steps: @@ -191,7 +191,7 @@ To delete an Audit Log sink, follow these steps: After you confirm the deletion, the Audit Log Sink is removed from your account and logs stop flowing to your stream. -## View an Audit Log {#view-an-audit-log} +## View an Audit Log {/* #view-an-audit-log */} An Audit Log can be viewed in the Temporal Cloud UI. 1. In the Temporal Cloud UI, select **Settings**. @@ -199,7 +199,7 @@ An Audit Log can be viewed in the Temporal Cloud UI. Up to 1000 events can be downloaded from the Audit Log UI to a local file. -## Access an Audit Log via API {#audit-log-api} +## Access an Audit Log via API {/* #audit-log-api */} An Audit Log can be accessed using the [Temporal Cloud Ops API](/ops). Use the API to access an Audit Log if you wish to make dashboards for viewing an Audit Log outside of Temporal Cloud. diff --git a/docs/cloud/billing-and-usage/actions-usage.mdx b/docs/cloud/billing-and-usage/actions-usage.mdx index 09493d19b7..e89f0b556d 100644 --- a/docs/cloud/billing-and-usage/actions-usage.mdx +++ b/docs/cloud/billing-and-usage/actions-usage.mdx @@ -23,7 +23,7 @@ tags: import { CaptionedImage } from '@site/src/components'; -## Usage {#usage} +## Usage {/* #usage */} Actions usage is tracked across an account in the [usage dashboard](https://cloud.temporal.io/usage) and is visible to Account Owners, Finance Admin and Global Admin. For individual Namespaces, usage can be seen in the @@ -31,7 +31,7 @@ Account Owners, Finance Admin and Global Admin. For individual Namespaces, usage ![Temporal Cloud Usage dashboard](/img/cloud/billing/usage-dashboard.png) -## Actions in Workflows {#actions-in-workflows} +## Actions in Workflows {/* #actions-in-workflows */} When viewing a Event history, events that represent a Billable Action are annotated with the number consumed by the event in the **Billable Actions** Column. These Actions are summarized at the top of the workflow. diff --git a/docs/cloud/billing-and-usage/billing.mdx b/docs/cloud/billing-and-usage/billing.mdx index 3eddf370ad..351d96cfc0 100644 --- a/docs/cloud/billing-and-usage/billing.mdx +++ b/docs/cloud/billing-and-usage/billing.mdx @@ -23,7 +23,7 @@ tags: -## Current balance {#current-balance} +## Current balance {/* #current-balance */} Your current balance card shows the balance for your current billing cycle and the date it was last updated. This balance adjusts with use and appears on the first line of your Invoices table. @@ -35,7 +35,7 @@ The minimum plan fee for your first month is prorated based on your sign-up date ::: -## Recent bill {#recent-bill} +## Recent bill {/* #recent-bill */} The "Recent Bill" card displays the previous bill amount. @@ -46,7 +46,7 @@ The "Recent Bill" card displays the previous bill amount. - If your account is set up for auto-payment, you don’t need to manually pay bills. However, you can choose to make manual payments whenever you wish -## Invoices {#invoice} +## Invoices {/* #invoice */} To review your invoices, follow these steps: @@ -74,7 +74,7 @@ During the current billing period, your invoice will not be finalized and the do ::: -## Credits {#credit-table} +## Credits {/* #credit-table */} The following information appears under the credits table: @@ -85,7 +85,7 @@ The following information appears under the credits table: ![Billing page showing Credits tab](/img/cloud/billing/billing-credits.png) -## Cost by Namespace {#cost-by-namespace} +## Cost by Namespace {/* #cost-by-namespace */} :::tip Temporal Cloud Billing API in Public Preview @@ -108,7 +108,7 @@ reflects your effective price, factoring in included Actions/Storage and tiered ::: -## Plans {#plans} +## Plans {/* #plans */} Account Owners and Finance Admins can access their Temporal Plan information on the plans page. For customers on a standard agreement you will be able to: diff --git a/docs/cloud/capacity-modes.mdx b/docs/cloud/capacity-modes.mdx index af155d2405..bb55307799 100644 --- a/docs/cloud/capacity-modes.mdx +++ b/docs/cloud/capacity-modes.mdx @@ -97,7 +97,7 @@ Actions that are external to the core Temporal service do not contribute to your * Capacity Related Actions ::: -## On-Demand Capacity {#on-demand-capacity} +## On-Demand Capacity {/* #on-demand-capacity */} Using On-Demand Capacity, your rate limit grows automatically along with your usage. @@ -131,7 +131,7 @@ This means that your default limit would be 800 APS. ![Usage graph showing increasing APS usage for one month, with occasional spikes, and a rising APS limit](/img/cloud/provisioned-capacity/usage_graph.png) -## Provisioned Capacity {#provisioned-capacity} +## Provisioned Capacity {/* #provisioned-capacity */} Provisioned Capacity provides an alternative to On-Demand Capacity by allowing you to control the limits on your Namespace based on your specific need. diff --git a/docs/cloud/connectivity/aws-connectivity.mdx b/docs/cloud/connectivity/aws-connectivity.mdx index 380b0c1b03..3cc11a6ef6 100644 --- a/docs/cloud/connectivity/aws-connectivity.mdx +++ b/docs/cloud/connectivity/aws-connectivity.mdx @@ -192,7 +192,7 @@ For Namespaces with [High Availability features](/cloud/high-availability), you The complete guidance — including single-cloud (AWS-only) HA, multi-cloud HA (AWS PrivateLink + GCP Private Service Connect), and a recommended failover-testing plan — lives on a single page: [Connectivity for High Availability](/cloud/high-availability/ha-connectivity). -## Direct VPCE targeting without per-Namespace DNS {#direct-vpce} +## Direct VPCE targeting without per-Namespace DNS {/* #direct-vpce */} For single-region Namespaces, you can avoid creating DNS records for each Namespace by pointing Workers directly at the VPC Endpoint and overriding the TLS Server Name Indicator (SNI): diff --git a/docs/cloud/export.mdx b/docs/cloud/export.mdx index 70f2b933b5..c17255c5a1 100644 --- a/docs/cloud/export.mdx +++ b/docs/cloud/export.mdx @@ -29,7 +29,7 @@ Exports run hourly, beginning 10 minutes after the hour. Allow up to 24 hours for a closed Workflow to appear in the exported file. Delivery is guaranteed at least once. -## What's in the exported data {#exported-data} +## What's in the exported data {/* #exported-data */} Each exported file contains one or more complete Workflow Execution histories serialized as protocol buffers using the [`WorkflowExecutions`](https://github.com/temporalio/api/blob/master/temporal/api/export/v1/message.proto) proto. @@ -126,14 +126,14 @@ This example shows a Workflow that started, ran one Activity, and completed: The outer `items` array can contain multiple Workflow Executions per file. Only the key fields are shown above. Actual events include additional fields like `version`, `taskId`, and `workerVersion`. -## Prerequisites {#prerequisites} +## Prerequisites {/* #prerequisites */} To use Workflow History Export, you must have: 1. A cloud account in the cloud provider where your Namespace is hosted. 2. An object storage bucket available to receive the exported History. -## Configure Workflow History Export {#configure} +## Configure Workflow History Export {/* #configure */} ### AWS @@ -143,14 +143,14 @@ To use Workflow History Export, you must have: [GCP GCS Export Configuration](/cloud/export/gcp-export-gcs) -## Verify export setup {#verify} +## Verify export setup {/* #verify */} From the Export configuration page, select **Verify**. This validates that Temporal can successfully write a test file to your object storage. If everything is configured correctly, you will see a `Success` status indicating Temporal has written to the object store. -## Monitor export progress {#monitor} +## Monitor export progress {/* #monitor */} After Export has been configured, you can check that it's still working in several ways: @@ -194,7 +194,7 @@ It can be useful to convert protos to another format to perform analytics on the * Each row in the table represents a single history event from a Workflow. To preserve their relationship post-conversion, the `workflowID` and `runID` is included in every row. * If you have enabled the codec server, the payload field is encrypted. This field may contain characters that are not recognized when loaded into a database so the payload field is excluded in this example. -## Export and High Availability Namespaces {#export-ha} +## Export and High Availability Namespaces {/* #export-ha */} ### Export Region Persistence diff --git a/docs/cloud/gcp-export-gcs.mdx b/docs/cloud/gcp-export-gcs.mdx index 84fefeb9ff..e0b1b333be 100644 --- a/docs/cloud/gcp-export-gcs.mdx +++ b/docs/cloud/gcp-export-gcs.mdx @@ -22,7 +22,7 @@ tags: import * as Components from '@site/src/components'; -## Prerequisites {#prerequisites} +## Prerequisites {/* #prerequisites */} Before configuring the Export sink, complete the following steps in Google Cloud. diff --git a/docs/cloud/get-started/api-keys.mdx b/docs/cloud/get-started/api-keys.mdx index 5f8a21397b..8592cdd9ac 100644 --- a/docs/cloud/get-started/api-keys.mdx +++ b/docs/cloud/get-started/api-keys.mdx @@ -34,7 +34,7 @@ Temporal Cloud API keys offer industry-standard identity-based authentication fo - [Troubleshoot your API key use](#troubleshooting) - [API keys: Frequently Asked Questions](#faqs) -## API key overview {#overview} +## API key overview {/* #overview */} Each Temporal Cloud API key is a unique identity linked to role-based access control (RBAC) settings to ensure secure and appropriate access. @@ -46,7 +46,7 @@ The authentication process follows this pathway: title="API key (authentication) → Identity (user or Service Account) → RBAC (authorization)" /> -## API key best practices {#best-practices} +## API key best practices {/* #best-practices */} - **Keep it secret; keep it safe**: Treat your API key like a password. Do not expose it in client-side code, public repositories, or other easily accessible locations. @@ -100,7 +100,7 @@ Check these setup details before using API keys: - Have access to the [Temporal Cloud UI](https://cloud.temporal.io/) or Temporal Cloud CLI ([tcld](https://docs.temporal.io/cloud/tcld/)) to create an API key. -## Global Administrator and Account Owner API key management {#manage-api-keys} +## Global Administrator and Account Owner API key management {/* #manage-api-keys */} Global Administrators and Account Owners can monitor, manage, disable, and delete API keys for any user or Service Account within their account. To manage your account’s API keys: @@ -124,7 +124,7 @@ is created and configured. ::: -## User API key management {#user-api-keys} +## User API key management {/* #user-api-keys */} Manage your personal API keys with the Temporal Cloud UI or `tcld`. These sections show you how to generate, manage, and remove API keys for a user. @@ -229,7 +229,7 @@ Temporal API keys automatically expire based on the specified expiration time. F For a broader machine-identity rotation strategy across API keys and Service Accounts, see [Managing Temporal Cloud access control](/best-practices/cloud-access-control). -## Manage API keys for Service Accounts {#serviceaccount-api-keys} +## Manage API keys for Service Accounts {/* #serviceaccount-api-keys */} Global Administrators and Account Owners can manage and generate API keys for _all_ Service Accounts in their account. Namespace Admins can manage and generate API keys for the Namespace-scoped Service Accounts they administer. @@ -344,7 +344,7 @@ Workflow access secure. ::: -## API keys for Namespace authentication {#namespace-authentication} +## API keys for Namespace authentication {/* #namespace-authentication */} Create a Namespace with API key authentication as an alternative to mTLS-based authentication by selecting "Allow API key authentication" during setup. @@ -355,7 +355,7 @@ directs traffic to the active region, so Workers and Clients don't need to chang See [accessing Namespaces](/cloud/namespaces#access-namespaces) for more information on endpoint options. -## Use API keys to authenticate {#using-apikeys} +## Use API keys to authenticate {/* #using-apikeys */} Authenticate with Temporal Cloud using API keys with the following clients: @@ -432,11 +432,11 @@ see To use an API key with the [Temporal Terraform Provider](/cloud/terraform-provider), pass the API key as a provider argument. -## Troubleshoot your API key use {#troubleshooting} +## Troubleshoot your API key use {/* #troubleshooting */} **Invalid API key errors**: Check that you copied the key correctly and that it hasn't been revoked or expired. -## API keys: Frequently Asked Questions {#faqs} +## API keys: Frequently Asked Questions {/* #faqs */} **Q: Can I issue and use multiple API keys for the same account?** diff --git a/docs/cloud/get-started/certificates.mdx b/docs/cloud/get-started/certificates.mdx index e6868890b5..941110d420 100644 --- a/docs/cloud/get-started/certificates.mdx +++ b/docs/cloud/get-started/certificates.mdx @@ -45,7 +45,7 @@ To update certificates, see All certificates used by Temporal Cloud must meet the following requirements. -## Requirements for CA certificates in Temporal Cloud {#certificate-requirements} +## Requirements for CA certificates in Temporal Cloud {/* #certificate-requirements */} Certificates provided to Temporal for your [Namespaces](/namespaces) _must_ meet the following requirements. @@ -95,7 +95,7 @@ An end-entity (leaf) certificate _must_ meet the following criteria: - The signing algorithm must be either RSA or ECDSA and must include SHA-256 or stronger message authentication. SHA-1 and MD5 cannot be used. -## How to issue root CA and end-entity certificates {#issue-certificates} +## How to issue root CA and end-entity certificates {/* #issue-certificates */} Temporal Cloud authenticates a client connection by validating the client certificate against one or more CA certificates that are configured for the specified Namespace. @@ -237,7 +237,7 @@ Follow the instructions to [upload the CA certificate](/cloud/certificates#updat and [configure your client](/cloud/certificates#configure-clients-to-use-client-certificates) with the end-entity certificate. -## How to control authorization for Temporal Cloud Namespaces {#control-authorization} +## How to control authorization for Temporal Cloud Namespaces {/* #control-authorization */} We recommend that an end-entity certificate be scoped to a specific Namespace to enforce the principle of least privilege. Temporal Cloud requires full CA chains, so you can achieve authorization in two ways. @@ -254,7 +254,7 @@ trusted authority for access to your Namespaces. [How to manage certificate filters in Temporal Cloud](#manage-certificate-filters) -## How to receive notifications about certificate expiration {#expiration-notifications} +## How to receive notifications about certificate expiration {/* #expiration-notifications */} To keep your Namespace secure and online, you must update the CA certificate for the Namespace _before_ the certificate expires. @@ -320,7 +320,7 @@ stricter controls, such as: - Rotating certificates regularly as a preventive measure - [Audit logs on a regular schedule](https://docs.temporal.io/cloud/audit-logs) -## How to add, update, and remove certificates in a Temporal Cloud Namespace {#manage-certificates} +## How to add, update, and remove certificates in a Temporal Cloud Namespace {/* #manage-certificates */} :::note @@ -399,7 +399,7 @@ Updating certificates using the following strategy allows for a zero-downtime ro 1. Run the `tcld namespace accepted-client-ca set` command again with the updated CA certificate bundle file. -## How to manage certificate filters in Temporal Cloud {#manage-certificate-filters} +## How to manage certificate filters in Temporal Cloud {/* #manage-certificate-filters */} To limit access to specific [end-entity certificates](#end-entity-certificates), create certificate filters. Each filter contains values for one or more of the following fields: @@ -479,7 +479,7 @@ To set or clear certificate filters, use the following [tcld](/cloud/tcld) comma To view the current certificate filters, use the [tcld namespace certificate-filters export](/cloud/tcld/namespace/#export) command. -## Configure clients to use client certificates {#configure-clients-to-use-client-certificates} +## Configure clients to use client certificates {/* #configure-clients-to-use-client-certificates */} - [Go SDK](/develop/go/client/temporal-client#connect-to-temporal-cloud) - [Java SDK](/develop/java/client/temporal-client#connect-to-temporal-cloud) @@ -488,7 +488,7 @@ To view the current certificate filters, use the - [TypeScript SDK](/develop/typescript/client/temporal-client#connect-to-temporal-cloud) - [.NET SDK](/develop/dotnet/client/temporal-client#connect-to-temporal-cloud) -### Configure Temporal CLI {#configure-temporal-cli} +### Configure Temporal CLI {/* #configure-temporal-cli */} To connect to a Temporal Namespace using the Temporal CLI and certificate authentication, specify your credentials and the TLS server name: diff --git a/docs/cloud/get-started/namespaces.mdx b/docs/cloud/get-started/namespaces.mdx index 198a4ec3db..319ceae6d2 100644 --- a/docs/cloud/get-started/namespaces.mdx +++ b/docs/cloud/get-started/namespaces.mdx @@ -36,7 +36,7 @@ identifiers, and gRPC endpoints in Temporal Cloud. - [Delete a Namespace](#delete-a-namespace) - [Tag a Namespace](#tag-a-namespace) -## What is a Cloud Namespace Name? {#temporal-cloud-namespace-name} +## What is a Cloud Namespace Name? {/* #temporal-cloud-namespace-name */} A Cloud Namespace Name is a customer-supplied name for a [Namespace](/namespaces) in Temporal Cloud. Each Namespace Name, such as `accounting-production`, is unique within the scope of a customer's account. It cannot be changed after @@ -59,7 +59,7 @@ For example: `accounting-production.123de` The full Namespace ID is shown in the Namespace list in the Temporal Cloud UI and in the output of `tcld namespace list`. See [Cloud Namespace ID](#temporal-cloud-namespace-id) for details. ::: -## What is a Temporal Cloud Account ID? {#temporal-cloud-account-id} +## What is a Temporal Cloud Account ID? {/* #temporal-cloud-account-id */} A Temporal Cloud Account ID is a unique customer identifier assigned by Temporal Technologies. Each Id is a short string of numbers and letters like `f45a2`, at least five characters long. This account identifier is part of every Namespace ID @@ -135,7 +135,7 @@ utility at a command line interface (CLI). Follow these steps. -## What is a Cloud Namespace Id? {#temporal-cloud-namespace-id} +## What is a Cloud Namespace Id? {/* #temporal-cloud-namespace-id */} A Cloud Namespace Id is a globally unique identifier for a [Namespace](/namespaces) in Temporal Cloud. A Namespace Id is formed by concatenating the following: @@ -147,7 +147,7 @@ formed by concatenating the following: For example, for the Account ID `123de` and Namespace Name `accounting-production`, the Namespace Id is `accounting-production.123de`. -## What is a Cloud gRPC Endpoint? {#temporal-cloud-grpc-endpoint} +## What is a Cloud gRPC Endpoint? {/* #temporal-cloud-grpc-endpoint */} Temporal Clients communicate between application code and a Temporal Server by sending and receiving messages via the gRPC protocol. gRPC is a Remote Procedure Call framework featuring low latency and high performance. gRPC provides @@ -167,7 +167,7 @@ A gRPC endpoint appears on the detail page for each Cloud Namespace. Follow thes See [How to access a Namespace in Temporal Cloud](/cloud/namespaces/#access-namespaces) for more information on different gRPC endpoint types and how to access them. -## How to create a Namespace in Temporal Cloud {#create-a-namespace} +## How to create a Namespace in Temporal Cloud {/* #create-a-namespace */} :::info @@ -234,7 +234,7 @@ See the [`tcld` namespace create](/cloud/tcld/namespace/#create) command referen -## What are some Namespace best practices? {#best-practices} +## What are some Namespace best practices? {/* #best-practices */} For guidance on how many Namespaces to create, how to split workloads across services or domains, and when to isolate tenants or teams, see [Namespace best practices](/best-practices/managing-namespace). @@ -242,7 +242,7 @@ tenants or teams, see [Namespace best practices](/best-practices/managing-namesp This page focuses on Temporal Cloud namespace mechanics such as naming rules, provisioning, authentication, tagging, and accessing Namespace endpoints. -## How to access a Namespace in Temporal Cloud {#access-namespaces} +## How to access a Namespace in Temporal Cloud {/* #access-namespaces */} {/* How to access a Namespace in Temporal Cloud */} @@ -309,7 +309,7 @@ For enhanced protection: - [AWS IP address ranges](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html) - [GCP IP address ranges](https://cloud.google.com/compute/docs/faq#find_ip_range) -## How to manage Namespaces in Temporal Cloud {#manage-namespaces} +## How to manage Namespaces in Temporal Cloud {/* #manage-namespaces */} {/* How to manage Namespaces in Temporal Cloud using Temporal Cloud UI */} @@ -357,7 +357,7 @@ To manage certificate filters, use the [tcld namespace certificate-filters](/clo commands. For more information, see [How to manage certificate filters in Temporal Cloud](/cloud/certificates#manage-certificate-filters). -## How to delete a Namespace in Temporal Cloud {#delete-a-namespace} +## How to delete a Namespace in Temporal Cloud {/* #delete-a-namespace */} :::info @@ -389,7 +389,7 @@ For further questions or concerns, contact [Support](https://docs.temporal.io/cl See the [tcld namespace delete](/cloud/tcld/namespace/#delete) command reference for details. -### Namespace deletion protection {#delete-protection} +### Namespace deletion protection {/* #delete-protection */} To prevent accidental Namespace deletion, Temporal Cloud provides a protection feature. When you enable Deletion Protection for your production environment Namespace, you ensure that critical data won't be deleted unintentionally. @@ -416,7 +416,7 @@ tcld namespace lifecycle set \ --enable-delete-protection ``` -## How to tag a Namespace in Temporal Cloud {#tag-a-namespace} +## How to tag a Namespace in Temporal Cloud {/* #tag-a-namespace */} Tags are key-value metadata pairs that can be attached to namespaces in Temporal Cloud to help operators organize, track, and manage namespaces more easily. diff --git a/docs/cloud/get-started/service-accounts.mdx b/docs/cloud/get-started/service-accounts.mdx index 0a6230cdad..11edf92ff3 100644 --- a/docs/cloud/get-started/service-accounts.mdx +++ b/docs/cloud/get-started/service-accounts.mdx @@ -157,7 +157,7 @@ The Service Account is deleted when it is no longer visible in the output of the -### Update a Service Account {#update} +### Update a Service Account {/* #update */} Update a Service Account's description using the Temporal Cloud UI or tcld. @@ -192,7 +192,7 @@ tcld service-account update --id "2f68507677904e09b9bcdbf93380bb95" -d "new desc -## Namespace-scoped Service Accounts {#scoped} +## Namespace-scoped Service Accounts {/* #scoped */} There is a special type of Service Account, called a Namespace-scoped Service Account, which shares the same functionality as the Service Accounts above, but is limited (or scoped) to a single namespace. @@ -218,7 +218,7 @@ Global Admins and Account Owners can also create Namespace-scoped Service Accoun As with regular Service Accounts, Namespace-scoped Service Accounts can be created using Temporal Cloud UI or tcld. -#### Using the Cloud UI {#scoped-ui} +#### Using the Cloud UI {/* #scoped-ui */} Currently, creating a Namespace-scoped Service Account from the Temporal Cloud UI happens on an individual [Namespace](/cloud/namespaces#manage-namespaces) page. If the current Namespace has API key authentication enabled, then there will be a `Generate API Key` button as a banner on the top of the Namespace page or in the `Authentication` section. diff --git a/docs/cloud/get-started/user-groups.mdx b/docs/cloud/get-started/user-groups.mdx index eed09f443c..b347c2fe29 100644 --- a/docs/cloud/get-started/user-groups.mdx +++ b/docs/cloud/get-started/user-groups.mdx @@ -35,7 +35,7 @@ One user can be assigned to many groups. In the event that a user's group member Only users with the Account Owner or Global Admin account-level [role](/cloud/manage-access/roles-and-permissions#account-level-roles) can manage user groups. -## How SCIM groups work with user groups {#scim-groups} +## How SCIM groups work with user groups {/* #scim-groups */} [SCIM groups](/cloud/scim) work similarly to user groups with respect to role assignment. Unlike a user group, the lifecycle of a SCIM group is fully managed by the SCIM integration which means: @@ -53,7 +53,7 @@ All user group administration requires an Account Owner or Global Admin account- ::: -## How to create a user group in your Temporal Cloud account {#create-group} +## How to create a user group in your Temporal Cloud account {/* #create-group */} User group names must be 3-64 characters long and can only contain lowercase letters, numbers, hyphens, and underscores. @@ -79,7 +79,7 @@ See the [Terraform provider documentation](https://registry.terraform.io/provide -## How to assign roles to a user group {#assign-group-roles} +## How to assign roles to a user group {/* #assign-group-roles */} @@ -119,7 +119,7 @@ See the [Terraform provider documentation](https://registry.terraform.io/provide -## How to manage users in a group {#assign-group-members} +## How to manage users in a group {/* #assign-group-members */} diff --git a/docs/cloud/get-started/users.mdx b/docs/cloud/get-started/users.mdx index b0ab4a8b22..9db917fa92 100644 --- a/docs/cloud/get-started/users.mdx +++ b/docs/cloud/get-started/users.mdx @@ -31,7 +31,7 @@ Namespaces. Each user can only perform an action if they have a role that grants When you register for Temporal Cloud without joining an existing account, you are assigned the Account Owner role for a new account. You can then invite other users to join the account and assign them roles. -## Invite users to your Temporal Cloud account {#invite-users} +## Invite users to your Temporal Cloud account {/* #invite-users */} import InvitationContent from '@site/docs/cloud/get-started/user-invite.mdx'; @@ -40,7 +40,7 @@ import InvitationContent from '@site/docs/cloud/get-started/user-invite.mdx'; Global Admin roles cannot assign the Account Owner role or the Finance Admin role to new users they invite to the account. -## Update a user's account-level role {#update-roles} +## Update a user's account-level role {/* #update-roles */} With Global Admin or Account Owner privileges, you can update any user's account-level [role](/cloud/manage-access/roles-and-permissions#account-level-roles). The Account Owner role can only be granted by @@ -99,7 +99,7 @@ Available roles: `ROLE_OWNER` | `ROLE_ADMIN` | `ROLE_DEVELOPER` | `ROLE_FINANCE_ -## Update a user's Namespace-level permissions {#update-permissions} +## Update a user's Namespace-level permissions {/* #update-permissions */} With Account Owner, Global Admin, or Namespace Admin privileges, you can update [Namespace-level permissions](/cloud/manage-access/roles-and-permissions#namespace-level-permissions) for users within @@ -169,7 +169,7 @@ Available permissions: `PERMISSION_ADMIN` | `PERMISSION_WRITE` | `PERMISSION_REA -## Delete a user from your Temporal Cloud account {#delete-users} +## Delete a user from your Temporal Cloud account {/* #delete-users */} With Account Owner or Global Admin privileges, you can delete a user from your Temporal Cloud account. diff --git a/docs/cloud/high-availability/enable.mdx b/docs/cloud/high-availability/enable.mdx index b4c2a29488..fdb33c5cc5 100644 --- a/docs/cloud/high-availability/enable.mdx +++ b/docs/cloud/high-availability/enable.mdx @@ -20,7 +20,7 @@ Using private network connectivity with a HA namespace requires extra setup. See There are charges associated with Replication and enabling High Availability features. For pricing details, visit Temporal Cloud's [Pricing](/cloud/pricing) page. -## Create a Namespace with High Availability features {#create} +## Create a Namespace with High Availability features {/* #create */} To create a new Namespace with High Availability features, you can use the Temporal Cloud UI or the tcld command line utility. @@ -61,7 +61,7 @@ If using API key authentication with the `--api-key` flag, you must add it direc Temporal Cloud sends an email alert to all Namespace Admins once your Namespace replica is ready for use. -## Add High Availability to an existing Namespace {#upgrade} +## Add High Availability to an existing Namespace {/* #upgrade */} A replica can be added after a namespace has already been created. @@ -103,7 +103,7 @@ Temporal Cloud sends an email alert once your Namespace is ready for use. -## Change a replica location {#changing} +## Change a replica location {/* #changing */} Temporal Cloud can't change replica locations directly. To change a replica's location, you need to remove the replica and add a new one. @@ -127,7 +127,7 @@ Follow these steps to change the replica location: You will receive an email alert once your Namespace is ready for use. -## Disable High Availability (remove a replica) {#disable} +## Disable High Availability (remove a replica) {/* #disable */} To disable High Availability features on a Namespace, remove the replica from that Namespace. Removing a replica disables all High Availability features: diff --git a/docs/cloud/high-availability/failovers/index.mdx b/docs/cloud/high-availability/failovers/index.mdx index 8635f49042..5a5d816ba6 100644 --- a/docs/cloud/high-availability/failovers/index.mdx +++ b/docs/cloud/high-availability/failovers/index.mdx @@ -94,7 +94,7 @@ is warranted are: takes effect, and the later one is a no-op. A user-triggered failover does not conflict with Temporal's automatic failover. -## The failover process {#failover-process} +## The failover process {/* #failover-process */} The failover process is the same whether it is triggered automatically by Temporal or manually by a user. @@ -120,7 +120,7 @@ The failover process is the same whether it is triggered automatically by Tempor user triggers another failover. See [failback options](/cloud/high-availability/failovers/manage#failbacks) for details. -## Post-failover events {#post-failover-events} +## Post-failover events {/* #post-failover-events */} After any failover, whether triggered by you or by Temporal, an event appears in both the [Temporal Cloud Web UI](https://cloud.temporal.io/namespaces) (on the Namespace detail page) and in your audit logs. The audit log entry uses the `"operation": "FailoverNamespace"` event. Temporal Cloud [notifies you via email](/cloud/notifications#admin-notifications) whenever a failover occurs. @@ -137,7 +137,7 @@ When the network partition resolves and the regions can communicate again, Tempo [conflict resolution](#conflict-resolution) process reconciles the divergent histories and determines which region remains active. -## Conflict resolution {#conflict-resolution} +## Conflict resolution {/* #conflict-resolution */} Namespaces with replicas rely on asynchronous event replication. Updates made to the primary may not immediately be reflected in the replica due to , particularly during failovers. In the event of a diff --git a/docs/cloud/high-availability/failovers/manage.mdx b/docs/cloud/high-availability/failovers/manage.mdx index 33b75780ca..f204a3d5de 100644 --- a/docs/cloud/high-availability/failovers/manage.mdx +++ b/docs/cloud/high-availability/failovers/manage.mdx @@ -20,7 +20,7 @@ import { ToolTipTerm, DiscoverableDisclosure } from '@site/src/components'; import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -## Trigger a failover {#trigger-failover} +## Trigger a failover {/* #trigger-failover */} You can trigger a failover manually using the Temporal Cloud Web UI, the tcld CLI, or the Cloud Ops API. @@ -127,7 +127,7 @@ Once the failover async operation returns successfully, the Namespace will be fa the failover Workflow. In the rare event that an internal error prevents the failover from completing, the Temporal on-call team is automatically paged to intervene and force the failover to completion. -## Return to the primary with failbacks {#failbacks} +## Return to the primary with failbacks {/* #failbacks */} Failback behavior depends on whether the failover was automatic or manually triggered. @@ -167,7 +167,7 @@ Temporal Cloud Web UI on your Namespace's detail page: - If the most recent failover was **user-triggered**, then the Namespace will _not_ be automatically failed back. You must trigger the failback yourself. -## Disable Temporal-initiated failovers {#disabling-temporal-initiated} +## Disable Temporal-initiated failovers {/* #disabling-temporal-initiated */} When you add a replica to a Namespace, Temporal Cloud automatically fails over the Namespace to its replica in the event of an outage. _This is the recommended and default option._ @@ -202,7 +202,7 @@ If using API key authentication with the `--api-key` flag, you must add it direc To restore the default behavior, unselect the option in the Web UI or change `true` to `false` in the CLI command. -## Workers and failovers {#worker} +## Workers and failovers {/* #worker */} Enabling High Availability for Namespaces does not require specific Worker configuration. When a Namespace fails over to the replica, the DNS redirection orchestrated by Temporal ensures that your existing Workers continue to poll the @@ -218,7 +218,7 @@ When a Namespace fails over to a replica in a different region, Workers will be Temporal Cloud enforces a maximum connection lifetime of 5 minutes, which gives your Workers an opportunity to re-resolve the DNS. -## Test failovers {#testing} +## Test failovers {/* #testing */} Temporal recommends regular failover testing for mission-critical applications in production. By testing in non-emergency conditions, you verify that your application continues to function even when parts of the infrastructure diff --git a/docs/cloud/high-availability/index.mdx b/docs/cloud/high-availability/index.mdx index 1600db9d83..50d60b5707 100644 --- a/docs/cloud/high-availability/index.mdx +++ b/docs/cloud/high-availability/index.mdx @@ -46,7 +46,7 @@ This provides the basis of the 99.9% service level agreement for Temporal Cloud However some critical use cases--such as customer-facing applications--require even better availability. That is where Temporal Cloud's High Availability features come in. -## High Availability features {#high-availability-features} +## High Availability features {/* #high-availability-features */} High Availability features extend Temporal Cloud's replication across regions and cloud providers, so your Namespace keeps running even when a whole region or cloud provider goes down: diff --git a/docs/cloud/manage-access/index.mdx b/docs/cloud/manage-access/index.mdx index ef58f918cd..5afa4335a7 100644 --- a/docs/cloud/manage-access/index.mdx +++ b/docs/cloud/manage-access/index.mdx @@ -72,7 +72,7 @@ Temporal Cloud supports SAML and SCIM for integration with your organization's i ## Troubleshoot account access issues -### Recover your account after losing access to your authenticator app {#mfa-recovery} +### Recover your account after losing access to your authenticator app {/* #mfa-recovery */} Accounts registered with email and password require multi-factor authentication (MFA) with an authenticator app. If you lose access to your authenticator app, you can still log in by clicking **Try another method** on the MFA screen. From @@ -84,7 +84,7 @@ there, you can either: Once you're logged in, you can reset your authenticator app by navigating to **My Profile** > **Password and Authentication** and then clicking **Authenticator App** > **Remove method**. -### Reset your password {#reset-password} +### Reset your password {/* #reset-password */} If you're currently logged in and would like to change your password, click your profile icon at the top right of the Temporal Cloud UI, navigate to **My Profile** > **Password and Authentication**, and then click **Reset Password**. @@ -93,7 +93,7 @@ If you're not currently logged in, navigate to the login page of the Temporal Cl **Continue**, and then select **Forgot password**. In both cases, you will receive an email with instructions on how to reset your password. -### Sign in after email domain changes {#email-domain-change} +### Sign in after email domain changes {/* #email-domain-change */} If your organization changed its email domain (for example, from `@oldcompany.com` to `@newcompany.com`), you may be unable to sign in to Temporal Cloud with your existing account. diff --git a/docs/cloud/manage-access/permissions-reference.mdx b/docs/cloud/manage-access/permissions-reference.mdx index f3b8bda235..926eebaca7 100644 --- a/docs/cloud/manage-access/permissions-reference.mdx +++ b/docs/cloud/manage-access/permissions-reference.mdx @@ -17,7 +17,7 @@ Temporal Cloud access controls are organized across two scopes: Within each scope, permissions apply to publicly documented [Temporal Cloud Ops API](https://docs.temporal.io/ops) endpoints and to additional non-Cloud Ops capabilities, such as Temporal Cloud UI and internal automation behaviors. -## Account-level access {#account-level-access} +## Account-level access {/* #account-level-access */} Account-level access is granted to users and service accounts by assigning them an account-level role. Temporal Cloud supports the following account-level roles: diff --git a/docs/cloud/manage-access/roles-and-permissions.mdx b/docs/cloud/manage-access/roles-and-permissions.mdx index a80ffb227c..30da74498a 100644 --- a/docs/cloud/manage-access/roles-and-permissions.mdx +++ b/docs/cloud/manage-access/roles-and-permissions.mdx @@ -62,7 +62,7 @@ We strongly recommend the following precautions when assigning the Account Owner This latter rule is useful for anyone on your team who may need to be contacted urgently, regardless of their Account role. -## Namespace-level permissions {#namespace-level-permissions} +## Namespace-level permissions {/* #namespace-level-permissions */} Namespace-level permissions govern access to resources within a Namespace, such as the following: diff --git a/docs/cloud/metrics/general-setup.mdx b/docs/cloud/metrics/general-setup.mdx index d202a2c863..7a5ad4ffc6 100644 --- a/docs/cloud/metrics/general-setup.mdx +++ b/docs/cloud/metrics/general-setup.mdx @@ -39,7 +39,7 @@ You will learn how to do the following: - [Configure an endpoint using tcld](#configure-via-cli-tcld) - [Query for metrics with a PromQL endpoint](#query-promql) -## Configure using the UI {#configure-via-ui} +## Configure using the UI {/* #configure-via-ui */} **How to configure a metrics endpoint using Temporal Cloud UI** @@ -98,7 +98,7 @@ $ curl --cert client.pem --key client-key.pem "https://.tmprl.cloud/ } ``` -## Configure endpoint using tcld {#configure-via-cli-tcld} +## Configure endpoint using tcld {/* #configure-via-cli-tcld */} **How to configure a metrics endpoint using the tcld CLI.** @@ -110,7 +110,7 @@ To disable a metrics endpoint, use [`tcld account metrics disable`](/cloud/tcld/ For more information, see [tcld account metrics command](/cloud/tcld/account#metrics). -## Query for metrics with a PromQL endpoint {#query-promql} +## Query for metrics with a PromQL endpoint {/* #query-promql */} Temporal Cloud emits metrics in a Prometheus-supported format. Prometheus is an open-source toolkit for alerting and monitoring. diff --git a/docs/cloud/metrics/index.mdx b/docs/cloud/metrics/index.mdx index 46013eecd3..572bcca1f8 100644 --- a/docs/cloud/metrics/index.mdx +++ b/docs/cloud/metrics/index.mdx @@ -60,7 +60,7 @@ For a Worker-focused view of how to combine these signals, see [Monitor worker h SDK metrics are emitted by your Workers and Clients. For setup instructions, see [SDK metrics setup](/cloud/metrics/sdk-metrics-setup). -## PromQL Endpoint (Deprecated) {#promql-deprecated} +## PromQL Endpoint (Deprecated) {/* #promql-deprecated */} :::danger PromQL endpoint deprecated diff --git a/docs/cloud/metrics/openmetrics/metrics-integrations.mdx b/docs/cloud/metrics/openmetrics/metrics-integrations.mdx index 641466f04d..ddeada44e8 100644 --- a/docs/cloud/metrics/openmetrics/metrics-integrations.mdx +++ b/docs/cloud/metrics/openmetrics/metrics-integrations.mdx @@ -105,7 +105,7 @@ The integration runs on a host (Linux, Windows, or Kubernetes) with the New Reli For New Relic-side details, see the [New Relic integration page](https://docs.newrelic.com/docs/infrastructure/host-integrations/host-integrations-list/temporal-cloud-integration/). -### Prometheus \+ Grafana {#prometheus-grafana} +### Prometheus \+ Grafana {/* #prometheus-grafana */} Self hosted Prometheus can be used to scrape the OpenMetrics endpoint. diff --git a/docs/cloud/metrics/prometheus-grafana.mdx b/docs/cloud/metrics/prometheus-grafana.mdx index dc7fe93a4d..dbba84ba3c 100644 --- a/docs/cloud/metrics/prometheus-grafana.mdx +++ b/docs/cloud/metrics/prometheus-grafana.mdx @@ -219,7 +219,7 @@ For more examples on setting metrics endpoints in other SDKs, see the metrics sa - [Java SDK Samples](https://github.com/temporalio/samples-java/tree/main/core/src/main/java/io/temporal/samples/metrics) - [Go SDK Samples](https://github.com/temporalio/samples-go/tree/main/metrics) -## Grafana data source configuration {#grafana-data-source-configuration} +## Grafana data source configuration {/* #grafana-data-source-configuration */} **How to configure the Temporal Cloud metrics data source in Grafana.** diff --git a/docs/cloud/metrics/reference.mdx b/docs/cloud/metrics/reference.mdx index 8b733a7b0d..c791ea9dfd 100644 --- a/docs/cloud/metrics/reference.mdx +++ b/docs/cloud/metrics/reference.mdx @@ -62,13 +62,13 @@ Please note: ::: -## Available Temporal Cloud metrics {#available-metrics} +## Available Temporal Cloud metrics {/* #available-metrics */} **What metrics are emitted from Temporal Cloud?** The following metrics are emitted for your Namespaces: -### Frontend Service metrics {#frontend} +### Frontend Service metrics {/* #frontend */} #### temporal_cloud_v0_frontend_service_error_count @@ -94,7 +94,7 @@ Count of state transitions for each Namespace. Approximate count of Temporal Cloud Actions. Labels: temporal_account, temporal_namespace, is_background, namespace_mode -### Poll metrics {#poll} +### Poll metrics {/* #poll */} #### temporal_cloud_v0_poll_success_count @@ -111,7 +111,7 @@ Labels: temporal_account, temporal_namespace, operation, task_type, temporal_ser When no tasks are available for a poller before timing out. Labels: temporal_account, temporal_namespace, operation, task_type, temporal_service_type -### Replication lag metrics {#replication-lag} +### Replication lag metrics {/* #replication-lag */} #### temporal_cloud_v0_replication_lag_bucket @@ -128,7 +128,7 @@ Labels: temporal_account, temporal_namespace The sum of [replication lag](/cloud/metrics/openmetrics/metrics-reference#temporal_cloud_v1_replication_lag_p99) during a specific time interval for a Namespace with high availability. Labels: temporal_account, temporal_namespace -### Schedule metrics {#schedule} +### Schedule metrics {/* #schedule */} #### temporal_cloud_v0_schedule_action_success_count @@ -150,7 +150,7 @@ Labels: temporal_account, temporal_namespace Workflows that were delayed due to exceeding a rate limit. Labels: temporal_account, temporal_namespace -### Service latency metrics {#service-latency} +### Service latency metrics {/* #service-latency */} #### temporal_cloud_v0_service_latency_bucket @@ -167,7 +167,7 @@ Labels: temporal_account, temporal_namespace, operation, temporal_service_type Sum of latency observation time for `SignalWithStartWorkflowExecution`, `SignalWorkflowExecution`, `StartWorkflowExecution` operations. Labels: temporal_account, temporal_namespace, operation, temporal_service_type -### Workflow metrics {#workflow} +### Workflow metrics {/* #workflow */} #### temporal_cloud_v0_workflow_cancel_count @@ -199,7 +199,7 @@ Labels: temporal_account, temporal_namespace, operation, temporal_service_type Workflows that timed out before completing execution. Labels: temporal_account, temporal_namespace, operation, temporal_service_type -## Metrics labels {#metrics-labels} +## Metrics labels {/* #metrics-labels */} **What labels can you use to filter metrics?** @@ -228,7 +228,7 @@ The following is an example of how you can filter metrics using labels: temporal_cloud_v0_poll_success_count{__rollup__="true", operation="TaskQueueMgr", task_type="Activity", temporal_account="12345", temporal_namespace="your_namespace.12345", temporal_service_type="matching"} ``` -## Operations {#metrics-operations} +## Operations {/* #metrics-operations */} **What operation labels are captured by Temporal Cloud?** diff --git a/docs/cloud/metrics/sdk-metrics-setup.mdx b/docs/cloud/metrics/sdk-metrics-setup.mdx index adaf2a83e1..ddc6ddc37f 100644 --- a/docs/cloud/metrics/sdk-metrics-setup.mdx +++ b/docs/cloud/metrics/sdk-metrics-setup.mdx @@ -43,7 +43,7 @@ Ensure Prometheus and Grafana are installed. - [TypeScript](/develop/typescript/client/temporal-client#connect-to-temporal-cloud) - [.NET](/develop/dotnet/client/temporal-client#connect-to-temporal-cloud) -## Expose a metrics endpoint {#sdk-metrics-setup} +## Expose a metrics endpoint {/* #sdk-metrics-setup */} You must configure a Prometheus scrape endpoint for Prometheus to collect and aggregate your SDK metrics. Each language development guide has details on how to set this up. @@ -65,7 +65,7 @@ For working examples of how to configure metrics in each SDK, see the metrics sa Some examples use OpenTelemtry to instrument metrics. It is useful to use a [Prometheus exporter with OpenTelemetry](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/prometheusexporter) to expose metrics for scraping. -## Configure Prometheus {#prometheus-configuration} +## Configure Prometheus {/* #prometheus-configuration */} For Temporal SDKs, you must have Prometheus running and configured to listen on the scrape endpoints exposed in your application code. @@ -95,7 +95,7 @@ See the [Prometheus documentation](https://prometheus.io/docs/introduction/first To check whether Prometheus is receiving metrics from your SDK target, go to [http://localhost:9090](http://localhost:9090) and navigate to **Status > Targets**. The status of your target endpoint defined in your configuration appears here. -## Add an SDK metrics data source in Grafana {#grafana-data-source-configuration} +## Add an SDK metrics data source in Grafana {/* #grafana-data-source-configuration */} Depending on how you use Grafana, you can either install and run it locally, run it as a Docker container, or log in to Grafana Cloud to set up your data sources. @@ -119,7 +119,7 @@ Verify your Prometheus configuration and restart Prometheus. If you're running Grafana as a container, you can set your SDK metrics Prometheus data source in your Grafana configuration. See the example Grafana configuration described in the [Prometheus and Grafana setup for open-source Temporal Service](/self-hosted-guide/monitoring#grafana) article. -## Set up Grafana dashboards {#grafana-dashboards-setup} +## Set up Grafana dashboards {/* #grafana-dashboards-setup */} To set up SDK metrics dashboards in Grafana, you can use the UI or configure them directly in your Grafana deployment. diff --git a/docs/cloud/migrate/automated.mdx b/docs/cloud/migrate/automated.mdx index ee046c3a94..88e5104a50 100644 --- a/docs/cloud/migrate/automated.mdx +++ b/docs/cloud/migrate/automated.mdx @@ -350,7 +350,7 @@ Use the following checklist prior to finalizing the migration: lead to unexpected symptoms and optimizations. - Know how to reach out to your Temporal Solutions Architect (SA) and Account Executive (AE) for assistance. -### Confirm complete {#confirm-complete} +### Confirm complete {/* #confirm-complete */} Once a Namespace has been transferred to the cloud and validated, the migration will be completed. Note that this step is final and may not be undone. Once performed, Workflow replication from the cloud Namespace to the self-hosted server diff --git a/docs/cloud/notifications.mdx b/docs/cloud/notifications.mdx index 431720ddc3..5d40998ea3 100644 --- a/docs/cloud/notifications.mdx +++ b/docs/cloud/notifications.mdx @@ -19,12 +19,12 @@ tags: - Billing --- -## Get notified about Temporal Cloud status {#cloud-status} +## Get notified about Temporal Cloud status {/* #cloud-status */} In the event of an incident, Temporal updates the [Temporal Cloud status page](https://status.temporal.io/) with important updates. Users can subscribe to updates in their preferred mode (e.g. email, Slack, SMS, etc.) by visiting this page. -## Get notified about administrative events {#admin-notifications} +## Get notified about administrative events {/* #admin-notifications */} Temporal Cloud sends emails to notify users of important administrative events. diff --git a/docs/cloud/rto-rpo.mdx b/docs/cloud/rto-rpo.mdx index 0e7ba354c0..505381ef88 100644 --- a/docs/cloud/rto-rpo.mdx +++ b/docs/cloud/rto-rpo.mdx @@ -74,7 +74,7 @@ Availability, Temporal uses the backup to restore as much data as feasible. The following sections explain each type of outage in more detail, including the blast radius, Temporal Cloud features that mitigate the outage, and whether the outage is included in the SLA calculation. -### Availability Zone outage {#availability-zone-outage} +### Availability Zone outage {/* #availability-zone-outage */} An [Availability Zone](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) @@ -125,7 +125,7 @@ When using Temporal Cloud (no additional features required): - **Zero RPO.** Writes to Workflow state are synchronously replicated across all three AZs before being acknowledged back to the Client, so an AZ failure cannot cause data loss. -### Cell outage {#cell-outage} +### Cell outage {/* #cell-outage */} Temporal Cloud runs on a [cell architecture](https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/what-is-a-cell-based-architecture.html). @@ -159,7 +159,7 @@ When using Same-region Replication, Multi-region Replication, or Multi-cloud Rep Even though the RPO target is under 1 minute, data is virtually never "lost" thanks to Temporal's built-in Recovery and Conflict Resolution process, which reconciles state between the active and replica when the outage is over. -### Cloud Region outage {#cloud-region-outage} +### Cloud Region outage {/* #cloud-region-outage */} A cloud region as a whole can become degraded, with effects that span beyond any single cell or Availability Zone. @@ -193,7 +193,7 @@ When using Multi-region Replication or Multi-cloud Replication for Temporal-mana Even though the RPO target is under 1 minute, data is virtually never "lost" thanks to Temporal's built-in Recovery and Conflict Resolution process, which reconciles state between the active and replica when a failover occurs. -### Cloud-wide outage {#cloud-wide-outage} +### Cloud-wide outage {/* #cloud-wide-outage */} On rare occasions, an issue affects two or more regions of a single cloud provider at once. Any simultaneous outage of two or more regions in the same cloud provider is treated as a cloud-wide outage. @@ -228,12 +228,12 @@ When using Multi-cloud Replication for Temporal-managed failover: Even though the RPO target is under 1 minute, data is virtually never "lost" thanks to Temporal's built-in Recovery and Conflict Resolution process, which reconciles state between the active and replica when a failover occurs. -## How RTO and RPO are measured {#how-rto-and-rpo-are-measured} +## How RTO and RPO are measured {/* #how-rto-and-rpo-are-measured */} Temporal Cloud achieves its RTO and RPO targets through [High Availability](/cloud/high-availability) replication. The following sections explain how each metric is measured and what factors can affect them. -### RPO {#how-rpo-is-measured} +### RPO {/* #how-rpo-is-measured */} Unlike a traditional database where data within the recovery point window may be permanently lost, Temporal Cloud durably persists all acknowledged data. After an outage resolves, Temporal's Recovery and Conflict Resolution process @@ -252,7 +252,7 @@ Temporal provides a Namespace. This metric approximates the recovery point the Namespace would achieve in a worst-case failure at that moment. Temporal recommends monitoring the replication lag and alerting if it rises above 1 minute. -### RTO {#how-rto-is-measured} +### RTO {/* #how-rto-is-measured */} The Recovery Time for a given incident is measured from the moment the incident begins to cause abnormal Namespace operation — for example, when unavailability or error rates rise above an acceptable level — to the moment the Namespace diff --git a/docs/cloud/saml.mdx b/docs/cloud/saml.mdx index f44a33efe3..bb16fecebe 100644 --- a/docs/cloud/saml.mdx +++ b/docs/cloud/saml.mdx @@ -38,7 +38,7 @@ SAML is included in the Business, Enterprise, and Mission Critical plans. For mo - [Okta](#configure-saml-with-okta) 1. [Share your connection information with us and test your connection.](#finish-saml-configuration) -## How to configure SAML with Microsoft Entra ID {#configure-saml-with-azure-ad} +## How to configure SAML with Microsoft Entra ID {/* #configure-saml-with-azure-ad */} If you want to use the general Microsoft login mechanism, you don't need to set up SAML with Entra ID. Just select **Continue with Microsoft** on the Temporal Cloud sign-in page. @@ -107,7 +107,7 @@ To use Entra ID as your SAML IdP, create a Microsoft Entra ID Enterprise applica To finish setting up Microsoft Entra ID as your SAML IdP, see [Finish SAML configuration](#finish-saml-configuration). -## How to configure SAML with Okta {#configure-saml-with-okta} +## How to configure SAML with Okta {/* #configure-saml-with-okta */} To use Okta as your SAML IdP, configure a new Okta application integration. @@ -157,7 +157,7 @@ To use Okta as your SAML IdP, configure a new Okta application integration. To finish setting up Okta as your SAML IdP, see the next section, [Finish SAML configuration](#finish-saml-configuration). -## How to finish your SAML configuration {#finish-saml-configuration} +## How to finish your SAML configuration {/* #finish-saml-configuration */} After you configure SAML with your IdP, we can finish the configuration on our side. [Create a support ticket](/cloud/support#support-ticket) that includes the following information: diff --git a/docs/cloud/scim.mdx b/docs/cloud/scim.mdx index 80b1594cb7..610472a79a 100644 --- a/docs/cloud/scim.mdx +++ b/docs/cloud/scim.mdx @@ -64,7 +64,7 @@ You can always change a user's or group's Account Role from the Temporal Cloud i ::: -## Onboarding with SCIM and Okta {#configure-scim-with-okta} +## Onboarding with SCIM and Okta {/* #configure-scim-with-okta */} 1. Temporal Support enables the SCIM integration on your account. Enabling integration automatically emails a configuration link to your Okta administrator. diff --git a/docs/cloud/service-health.mdx b/docs/cloud/service-health.mdx index febb3465c1..adf0c293d9 100644 --- a/docs/cloud/service-health.mdx +++ b/docs/cloud/service-health.mdx @@ -152,7 +152,7 @@ Persistent non-zero values are unexpected and indicate a hot resource. Use the ` Resource exhaustion is distinct from rate limiting against your account limits. For workloads that are throttled because they exceed their provisioned capacity, see [Monitoring Trends Against Limits](#rps-aps-rate-limits). Limits-driven throttling slows or stalls a workload, so it is generally the more important signal to monitor. -## Monitoring Trends Against Limits {#rps-aps-rate-limits} +## Monitoring Trends Against Limits {/* #rps-aps-rate-limits */} Tracking trends against your account limits is the most important throttling signal to monitor. Unlike [Resource Exhaustion](#detecting-resource-exhaustion), which usually self-heals through retries, hitting a limit slows or stalls progress until the workload backs off or your capacity is increased. diff --git a/docs/cloud/tcld/account.mdx b/docs/cloud/tcld/account.mdx index cf60976cca..450f86f3bd 100644 --- a/docs/cloud/tcld/account.mdx +++ b/docs/cloud/tcld/account.mdx @@ -89,7 +89,7 @@ Alias: `v` Provide a name for the sink. -#### get {#account-audit-log-kinesis-get} +#### get {/* #account-audit-log-kinesis-get */} The `tcld account audit-log kinesis get` command gets an audit log sink. @@ -230,7 +230,7 @@ Alias: `v` Provide a name for the sink. -#### get {#account-audit-log-pubsub-get} +#### get {/* #account-audit-log-pubsub-get */} The `tcld account audit-log pubsub get` command gets an audit log sink. diff --git a/docs/cloud/tcld/generate-certificates.mdx b/docs/cloud/tcld/generate-certificates.mdx index c2c69f8cfd..5b1515a720 100644 --- a/docs/cloud/tcld/generate-certificates.mdx +++ b/docs/cloud/tcld/generate-certificates.mdx @@ -21,7 +21,7 @@ Alias: `gen` - [tcld generate-certificates certificate-authority-certificate](#certificate-authority-certificate) - [tcld generate-certificates end-entity-certificate](#end-entity-certificate) -## tcld generate-certificates certificate-authority-certificate {#certificate-authority-certificate} +## tcld generate-certificates certificate-authority-certificate {/* #certificate-authority-certificate */} The `tcld generate-certificates certificate-authority-certificate` command generates certificate authority (CA) certificates for Temporal Cloud. @@ -93,7 +93,7 @@ Alias: `--rsa` tcld generate-certificates certificate-authority-certificate --rsa-algorithm ``` -## tcld generate-certificates end-entity-certificate {#end-entity-certificate} +## tcld generate-certificates end-entity-certificate {/* #end-entity-certificate */} The `tcld generate-certificates end-entity-certificate` command generates end-entity (leaf) certificates for Temporal Cloud. diff --git a/docs/cloud/tcld/index.mdx b/docs/cloud/tcld/index.mdx index c52e3601eb..099291d2c6 100644 --- a/docs/cloud/tcld/index.mdx +++ b/docs/cloud/tcld/index.mdx @@ -41,7 +41,7 @@ Automatically confirm all prompts. You can specify the value for this modifier by setting the AUTO_CONFIRM environment variable. The default value is `false`. -## How to install tcld {#install-tcld} +## How to install tcld {/* #install-tcld */} You can install [tcld](/cloud/tcld) in two ways. diff --git a/docs/cloud/tcld/namespace.mdx b/docs/cloud/tcld/namespace.mdx index 5f9dc515a6..09a781a99f 100644 --- a/docs/cloud/tcld/namespace.mdx +++ b/docs/cloud/tcld/namespace.mdx @@ -1753,7 +1753,7 @@ tcld namespace update-codec-server \ --include-credentials true ``` -## update-high-availability {#update-high-availability} +## update-high-availability {/* #update-high-availability */} The `tcld namespace update-high-availability` command enables you to adjust settings for your [Namespace](/namespaces) with [High Availability features](/cloud/high-availability). This is set to `false` by default. diff --git a/docs/cloud/worker-health.mdx b/docs/cloud/worker-health.mdx index 367f7dba0e..116a759d5b 100644 --- a/docs/cloud/worker-health.mdx +++ b/docs/cloud/worker-health.mdx @@ -49,7 +49,7 @@ You can also inspect Workers and the Workers assigned to a Task Queue directly i ::: -## Minimal Observations {#minimal-observations} +## Minimal Observations {/* #minimal-observations */} These alerts should be configured and understood first to gain intelligence into your application health and behaviors. @@ -94,7 +94,7 @@ The following alerts build on the above to dive deeper into specific potential c - Alert when the value is growing over time for a given Task Queue -## Detect Task Backlog {#detect-task-backlog} +## Detect Task Backlog {/* #detect-task-backlog */} ### Symptoms of high Task backlog @@ -156,7 +156,7 @@ sum(increase(temporal_activity_schedule_to_start_latency_seconds_count[5m])) by This latency should be very low, close to zero. Any higher value indicates a bottleneck. -### Sync Match Rate {#sync-match-rate} +### Sync Match Rate {/* #sync-match-rate */} The sync match rate measures the rate of Tasks that are delivered to workers without having to be persisted (workers are up and available to pick them up) to the rate of all delivered tasks. @@ -188,7 +188,7 @@ sum by(temporal_namespace) ( The Sync Match Rate should be at least >95%, but preferably >99%. -### Handling Task backlog issues {#task-backlog-handling} +### Handling Task backlog issues {/* #task-backlog-handling */} Once you have detected the condition of a high Task backlog, consider the scenarios below to take action. @@ -255,7 +255,7 @@ Avoid setting a Schedule To Start Timeout when load testing for latency. ::: -## Detect greedy Worker resources {#detect-greedy-workers} +## Detect greedy Worker resources {/* #detect-greedy-workers */} **How to detect greedy Worker resources.** @@ -301,7 +301,7 @@ Consider sizing down your Workers by either: - Reducing the concurrent pollers per Worker, OR - Both of the above -## Detect misconfigured Workers {#detect-misconfigured-workers} +## Detect misconfigured Workers {/* #detect-misconfigured-workers */} **How to detect misconfigured Workers.** @@ -345,7 +345,7 @@ The work is not getting processed as fast as it should/can. Increase the `maxConcurrentWorkflowTaskExecutionSize` and `maxConcurrentActivityExecutionSize` values and keep an eye on your Worker resource metrics (CPU utilization, etc) to make sure you haven't created a new issue. -### Configure Sticky Execution Cache {#configure-sticky-cache} +### Configure Sticky Execution Cache {/* #configure-sticky-cache */} Sticky Execution means that a Worker caches a Workflow Execution Event History and creates a dedicated Task Queue to listen on. It significantly improves performance because the Temporal Service only sends new events to the Worker instead of entire Event Histories. @@ -375,7 +375,7 @@ max_over_time(temporal_sticky_cache_size{namespace="$namespace"}[10m]) rate(temporal_sticky_cache_total_forced_eviction_total{namespace="$namespace"}[5m])) ``` -## Manage Worker Heartbeating {#manage-worker-heartbeating} +## Manage Worker Heartbeating {/* #manage-worker-heartbeating */} :::tip SUPPORT, STABILITY, and DEPENDENCY INFO diff --git a/docs/develop/dotnet/activities/basics.mdx b/docs/develop/dotnet/activities/basics.mdx index 5c80e59aa8..f3940bea4c 100644 --- a/docs/develop/dotnet/activities/basics.mdx +++ b/docs/develop/dotnet/activities/basics.mdx @@ -11,7 +11,7 @@ tags: - Temporal SDKs --- -## Develop an Activity {#develop-activity} +## Develop an Activity {/* #develop-activity */} One of the primary things that Workflows do is orchestrate the execution of Activities. An Activity is a normal method execution that's intended to execute a single, well-defined action (either short or long-running), such as querying a database, calling a third-party API, or transcoding a media file. diff --git a/docs/develop/dotnet/activities/dynamic-activity.mdx b/docs/develop/dotnet/activities/dynamic-activity.mdx index 4efb9850f1..396c71c629 100644 --- a/docs/develop/dotnet/activities/dynamic-activity.mdx +++ b/docs/develop/dotnet/activities/dynamic-activity.mdx @@ -11,7 +11,7 @@ tags: - Temporal SDKs --- -## Set a Dynamic Activity {#set-a-dynamic-activity} +## Set a Dynamic Activity {/* #set-a-dynamic-activity */} **How to set a Dynamic Activity using the Temporal .NET SDK** diff --git a/docs/develop/dotnet/activities/execution.mdx b/docs/develop/dotnet/activities/execution.mdx index e3f6a1588c..5b4d375ca0 100644 --- a/docs/develop/dotnet/activities/execution.mdx +++ b/docs/develop/dotnet/activities/execution.mdx @@ -11,7 +11,7 @@ tags: - Activity --- -## Start Activity Execution {#activity-execution} +## Start Activity Execution {/* #activity-execution */} 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. @@ -49,6 +49,6 @@ Activity Execution semantics rely on several parameters. The only required value that needs to be set is either a [Schedule-To-Close Timeout](/encyclopedia/detecting-activity-failures#schedule-to-close-timeout) or a [Start-To-Close Timeout](/encyclopedia/detecting-activity-failures#start-to-close-timeout). These values are set in the Activity Options. -### Get Activity Execution results {#get-activity-results} +### Get Activity Execution results {/* #get-activity-results */} The Activity result is returned in the Task from the `ExecuteActivityAsync` call. diff --git a/docs/develop/dotnet/activities/standalone-activities.mdx b/docs/develop/dotnet/activities/standalone-activities.mdx index 76521c6684..bdf30e3839 100644 --- a/docs/develop/dotnet/activities/standalone-activities.mdx +++ b/docs/develop/dotnet/activities/standalone-activities.mdx @@ -53,7 +53,7 @@ This documentation uses source code from the [StandaloneActivity](https://github ::: -## Get Started with Standalone Activities {#get-started} +## Get Started with Standalone Activities {/* #get-started */} Prerequisites: @@ -121,7 +121,7 @@ src/StandaloneActivity/ └── TemporalioSamples.StandaloneActivity.csproj ``` -## Define your Activity {#define-activity} +## Define your Activity {/* #define-activity */} An Activity in the Temporal .NET SDK is a method decorated with the `[Activity]` attribute. The way you write a Standalone Activity is identical to how you write an Activity orchestrated by a Workflow. @@ -144,7 +144,7 @@ public static class MyActivities public record ComposeGreetingInput(string Greeting, string Name); ``` -## Run a Worker with the Activity registered {#run-worker} +## Run a Worker with the Activity registered {/* #run-worker */} Running a Worker for Standalone Activities is the same as running a Worker for Workflow Activities — you create a Worker, register the Activity, and run the Worker. The Worker doesn't need to know @@ -194,7 +194,7 @@ dotnet run --project src/StandaloneActivity worker Leave this terminal running - the Worker needs to stay up to process activities. -## Execute a Standalone Activity {#execute-activity} +## Execute a Standalone Activity {/* #execute-activity */} Use [`client.ExecuteActivityAsync()`](https://dotnet.temporal.io/api/Temporalio.Client.ITemporalClientExtensions.html) @@ -269,7 +269,7 @@ temporal activity execute \ --input '{"Greeting": "Hello", "Name": "World"}' ``` -## Start a Standalone Activity without waiting for the result {#start-activity} +## Start a Standalone Activity without waiting for the result {/* #start-activity */} Use [`client.StartActivityAsync()`](https://dotnet.temporal.io/api/Temporalio.Client.ITemporalClient.html) @@ -316,7 +316,7 @@ temporal activity start \ --input '{"Greeting": "Hello", "Name": "World"}' ``` -## Get a handle to an existing Standalone Activity {#get-activity-handle} +## Get a handle to an existing Standalone Activity {/* #get-activity-handle */} Use `client.GetActivityHandle()` to create a handle to a previously started Standalone Activity: @@ -330,7 +330,7 @@ var typedHandle = client.GetActivityHandle("my-activity-id", runId: "the You can use the handle to wait for the result, describe, cancel, or terminate the Activity. -## Wait for the result of a Standalone Activity {#get-activity-result} +## Wait for the result of a Standalone Activity {/* #get-activity-result */} Under the hood, calling `client.ExecuteActivityAsync()` is the same as calling `client.StartActivityAsync()` to durably enqueue the Standalone Activity, and then calling @@ -346,7 +346,7 @@ Or use the Temporal CLI to wait for a result by Activity ID: temporal activity result --activity-id my-standalone-activity-id ``` -## List Standalone Activities {#list-activities} +## List Standalone Activities {/* #list-activities */} Use [`client.ListActivitiesAsync()`](https://dotnet.temporal.io/api/Temporalio.Client.ITemporalClient.html) @@ -388,7 +388,7 @@ temporal activity list The query parameter accepts the same [List Filter](/list-filter) syntax used for [Workflow Visibility](/visibility). For example, `"ActivityType = 'ComposeGreeting' AND Status = 'Running'"`. -## Count Standalone Activities {#count-activities} +## Count Standalone Activities {/* #count-activities */} Use [`client.CountActivitiesAsync()`](https://dotnet.temporal.io/api/Temporalio.Client.ITemporalClient.html) @@ -423,7 +423,7 @@ Or use the Temporal CLI: temporal activity count ``` -## Run Standalone Activities with Temporal Cloud {#run-standalone-activities-temporal-cloud} +## Run Standalone Activities with Temporal Cloud {/* #run-standalone-activities-temporal-cloud */} The code samples on this page use `ClientEnvConfig.LoadClientConnectOptions()`, so the same code works against Temporal Cloud - just configure the connection via environment variables or a TOML diff --git a/docs/develop/dotnet/activities/timeouts.mdx b/docs/develop/dotnet/activities/timeouts.mdx index 5b4f9b552b..8cbb8eb309 100644 --- a/docs/develop/dotnet/activities/timeouts.mdx +++ b/docs/develop/dotnet/activities/timeouts.mdx @@ -17,7 +17,7 @@ tags: - Temporal SDKs --- -## Activity Timeouts {#activity-timeouts} +## Activity Timeouts {/* #activity-timeouts */} Each Activity Timeout controls the maximum duration of a different aspect of an Activity Execution. @@ -43,7 +43,7 @@ return await Workflow.ExecuteActivityAsync( new() { StartToCloseTimeout = TimeSpan.FromMinutes(5) }); ``` -### Set an Activity Retry Policy {#activity-retries} +### Set an Activity Retry Policy {/* #activity-retries */} A Retry Policy works in cooperation with the timeouts to provide fine controls to optimize the execution experience. @@ -61,7 +61,7 @@ return await Workflow.ExecuteActivityAsync( }); ``` -### Override the Retry interval with `nextRetryDelay` {#next-retry-delay} +### Override the Retry interval with `nextRetryDelay` {/* #next-retry-delay */} When you throw an [Application Failure](/references/failures#application-failure) and assign the `nextRetryDelay` field, its value replaces and overrides the Retry interval defined in the active Retry Policy. @@ -78,7 +78,7 @@ throw new ApplicationFailureException( nextRetryDelay: TimeSpan.FromSeconds(3 * attempt)); ``` -## Heartbeat an Activity {#activity-heartbeats} +## Heartbeat an Activity {/* #activity-heartbeats */} An [Activity Heartbeat](/encyclopedia/detecting-activity-failures#activity-heartbeat) is a ping from the [Worker Process](/workers#worker-process) that is executing the Activity to the [Temporal Service](/temporal-service). Each Heartbeat informs the Temporal Service that the [Activity Execution](/activity-execution) is making progress and the Worker has not crashed. @@ -112,7 +112,7 @@ public async Task MyActivityAsync() In addition to obtaining cancellation information, Heartbeats also support detail data that persists on the server for retrieval during Activity retry. If an Activity calls `Heartbeat(123, 456)` and then fails and is retried, `HeartbeatDetails` on the `ActivityInfo` returns an collection containing `123` and `456` on the next Run. -### Set a Heartbeat Timeout {#heartbeat-timeout} +### Set a Heartbeat Timeout {/* #heartbeat-timeout */} A [Heartbeat Timeout](/encyclopedia/detecting-activity-failures#heartbeat-timeout) works in conjunction with [Activity Heartbeats](/encyclopedia/detecting-activity-failures#activity-heartbeat). diff --git a/docs/develop/dotnet/best-practices/converters-and-encryption.mdx b/docs/develop/dotnet/best-practices/converters-and-encryption.mdx index 8f362cc1d8..b98972ffe6 100644 --- a/docs/develop/dotnet/best-practices/converters-and-encryption.mdx +++ b/docs/develop/dotnet/best-practices/converters-and-encryption.mdx @@ -32,7 +32,7 @@ The server itself never adds encryption over Payloads. Therefore, unless client-side encryption is implemented, Payload data will be persisted in non-encrypted form to the data store, and any Client that can make requests to a Temporal namespace (including the Temporal UI and CLI) will be able to read Payloads contained in Workflows. When working with sensitive data, you should always implement Payload encryption. -## Custom Payload Codec {#custom-payload-codec} +## Custom Payload Codec {/* #custom-payload-codec */} Custom Data Converters can change the default Temporal Data Conversion behavior by adding hooks, sending payloads to external storage, or performing different encoding steps. If you only need to change the encoding performed on your payloads -- by adding compression or encryption -- you can override the default Data Converter to use a new `PayloadCodec`. @@ -103,7 +103,7 @@ Refer to the [Codec Server](/production-deployment/data-encryption) documentatio Temporal SDKs provide a default [Payload Converter](/payload-converter) that can be customized to convert a custom data type to [Payload](/dataconversion#payload) and back. -### Conversion sequence {#conversion-sequence} +### Conversion sequence {/* #conversion-sequence */} The order in which your encoding Payload Converters are applied depend on the order given to the Data Converter. You can set multiple encoding Payload Converters to run your conversions. @@ -117,7 +117,7 @@ Temporal's Converter architecture looks like this: title="Temporal converter architecture" /> -### Custom Payload Converter {#custom-payload-converter} +### Custom Payload Converter {/* #custom-payload-converter */} Data converters are used to convert raw Temporal payloads to/from actual .NET types. A custom data converter can be set via the `DataConverter` option when creating a client. Data converters are a combination of payload converters, payload codecs, and failure converters. diff --git a/docs/develop/dotnet/best-practices/debugging.mdx b/docs/develop/dotnet/best-practices/debugging.mdx index c676b57e22..16de1c49a4 100644 --- a/docs/develop/dotnet/best-practices/debugging.mdx +++ b/docs/develop/dotnet/best-practices/debugging.mdx @@ -15,20 +15,20 @@ tags: - Errors --- -## Debugging {#debug} +## Debugging {/* #debug */} This page shows how to do the following: - [Debug in a development environment](#debug-in-a-development-environment) - [Debug in a production environment](#debug-in-a-development-production) -### Debug in a development environment {#debug-in-a-development-environment} +### Debug in a development environment {/* #debug-in-a-development-environment */} In developing Workflows, you can use the normal development tools of logging and a debugger to see what’s happening in your Workflow. 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 production environment {#debug-in-a-development-production} +### Debug in a production environment {/* #debug-in-a-development-production */} **How to debug in a production environment using the Temporal .NET SDK** diff --git a/docs/develop/dotnet/best-practices/error-handling.mdx b/docs/develop/dotnet/best-practices/error-handling.mdx index f790b0bbd1..7780ca75f0 100644 --- a/docs/develop/dotnet/best-practices/error-handling.mdx +++ b/docs/develop/dotnet/best-practices/error-handling.mdx @@ -19,7 +19,7 @@ tags: - Errors --- -## Raise and Handle Exceptions {#exception-handling} +## Raise and Handle Exceptions {/* #exception-handling */} In each Temporal SDK, error handling is implemented idiomatically, following the conventions of the language. Temporal uses several different error classes internally — for example, [`CancelledFailureException`](https://dotnet.temporal.io/api/Temporalio.Exceptions.CanceledFailureException.html) in the .NET SDK, to handle a Workflow cancellation. @@ -70,7 +70,7 @@ public Task SendBillAsync(Bill bill) You can alternately specify a list of errors that are non-retryable in your Activity [Retry Policy](/develop/dotnet/activities/timeouts#activity-retries). -## Failing Workflows {#workflow-failure} +## Failing Workflows {/* #workflow-failure */} One of the core design principles of Temporal is that an Activity Failure will never directly cause a Workflow Failure — a Workflow should never return as Failed unless deliberately. The default retry policy associated with Temporal Activities is to retry them until reaching a certain timeout threshold. diff --git a/docs/develop/dotnet/best-practices/testing-suite.mdx b/docs/develop/dotnet/best-practices/testing-suite.mdx index e64938c34d..8d7b967364 100644 --- a/docs/develop/dotnet/best-practices/testing-suite.mdx +++ b/docs/develop/dotnet/best-practices/testing-suite.mdx @@ -33,14 +33,14 @@ We generally recommend writing the majority of your tests as integration tests. Because the test server supports skipping time, use the test server for both end-to-end and integration tests with Workers. -## Test frameworks {#test-frameworks} +## Test frameworks {/* #test-frameworks */} **Compatible testing frameworks** The .NET SDK is compatible with any testing framework and does not have a specific recommendation. Most .NET SDK samples use [xUnit](https://xunit.net/). -## Testing Workflows {#testing-workflows} +## Testing Workflows {/* #testing-workflows */} **How to test Workflow Definitions using the Temporal .NET SDK** @@ -246,7 +246,7 @@ When testing Workflows, often you don't want to actually run the Activities. Activities are just methods with the `[Activity]` attribute. Simply write different/empty/fake/asserting ones and pass those to the Worker to have different activities called during the test. -## Testing Activities {#test-activities} +## Testing Activities {/* #test-activities */} **How to test Activity Definitions using the Temporal .NET SDK** @@ -263,7 +263,7 @@ The following important members are available on the environment to affect the a - `WorkerShutdownTokenSource` - Token source for issuing Worker shutdown. - `PayloadConverter` - Defaulted to default payload converter. -## Replay test {#replay} +## Replay test {/* #replay */} **How to do a Replay test using the Temporal .NET SDK** diff --git a/docs/develop/dotnet/client/temporal-client.mdx b/docs/develop/dotnet/client/temporal-client.mdx index fe8dbd7c31..77e0c10c6e 100644 --- a/docs/develop/dotnet/client/temporal-client.mdx +++ b/docs/develop/dotnet/client/temporal-client.mdx @@ -31,7 +31,7 @@ This page shows you how to do the following using the .NET SDK with the Temporal A Temporal Client cannot be initialized and used inside a Workflow. However, it is acceptable and common to use a Temporal Client inside an Activity to communicate with a Temporal Service. -## Connect to development Temporal Service {#connect-to-development-service} +## Connect to development Temporal Service {/* #connect-to-development-service */} Use [`TemporalClient.ConnectAsync`](https://dotnet.temporal.io/api/Temporalio.Client.TemporalClient.html#Temporalio_Client_TemporalClient_ConnectAsync_Temporalio_Client_TemporalClientConnectOptions_) @@ -251,7 +251,7 @@ namespace TemporalioSamples.Manual -## Connect to Temporal Cloud {#connect-to-temporal-cloud} +## Connect to Temporal Cloud {/* #connect-to-temporal-cloud */} You can connect to Temporal Cloud using either an [API key](/cloud/api-keys) or through mTLS. Connection to Temporal Cloud or any secured Temporal Service requires additional connection options compared to connecting to an unsecured @@ -462,7 +462,7 @@ myClient.Connection.ApiKey = myKeyUpdated; -## Start a Workflow {#start-workflow} +## Start a Workflow {/* #start-workflow */} **How to start a Workflow using the Temporal .NET SDK** @@ -486,7 +486,7 @@ var result = await client.ExecuteWorkflowAsync( Console.WriteLine("Result: {0}", result); ``` -## Get Workflow results {#get-workflow-results} +## Get Workflow results {/* #get-workflow-results */} **How to get the results of a Workflow Execution using the Temporal .NET SDK** diff --git a/docs/develop/dotnet/nexus/feature-guide.mdx b/docs/develop/dotnet/nexus/feature-guide.mdx index f0cebf214c..c874b7b7a5 100644 --- a/docs/develop/dotnet/nexus/feature-guide.mdx +++ b/docs/develop/dotnet/nexus/feature-guide.mdx @@ -41,7 +41,7 @@ This documentation uses source code derived from the [.NET Nexus sample](https:/ ::: -## Run the Temporal Development Server with Nexus enabled {#run-the-temporal-nexus-development-server} +## Run the Temporal Development Server with Nexus enabled {/* #run-the-temporal-nexus-development-server */} Prerequisites: @@ -58,7 +58,7 @@ This command automatically starts the Temporal development server with the Web U The Temporal Web UI should now be accessible at [http://localhost:8233](http://localhost:8233), and the Temporal Server should now be available for client connections on `localhost:7233`. -## Create caller and handler Namespaces {#create-caller-handler-namespaces} +## Create caller and handler Namespaces {/* #create-caller-handler-namespaces */} Before setting up Nexus endpoints, create separate Namespaces for the caller and handler. @@ -70,7 +70,7 @@ temporal operator namespace create --namespace nexus-simple-caller-namespace `nexus-simple-handler-namespace` will contain the Nexus Operation handler, and we will use a Workflow in `nexus-simple-caller-namespace` to call that Operation handler. We use different namespaces to demonstrate cross-Namespace Nexus calls. -## Create a Nexus Endpoint to route requests from caller to handler {#create-nexus-endpoint} +## Create a Nexus Endpoint to route requests from caller to handler {/* #create-nexus-endpoint */} After establishing caller and handler Namespaces, the next step is to create a Nexus Endpoint to route requests. @@ -83,7 +83,7 @@ temporal operator nexus endpoint create \ You can also use the Web UI to create the Namespaces and Nexus endpoint. -## Define the Nexus Service contract {#define-nexus-service-contract} +## Define the Nexus Service contract {/* #define-nexus-service-contract */} Defining a clear contract for the Nexus Service is crucial for smooth communication. @@ -128,7 +128,7 @@ public interface IHelloService } ``` -## Develop a Nexus Service and Operation handlers {#develop-nexus-service-operation-handlers} +## Develop a Nexus Service and Operation handlers {/* #develop-nexus-service-operation-handlers */} Nexus Operation handlers are typically defined in the same Worker as the underlying Temporal primitives they abstract. Operation handlers can decide if a given Nexus Operation will be synchronous or asynchronous. @@ -287,7 +287,7 @@ async Task RunHandlerWorkerAsync() } ``` -## Develop a caller Workflow that uses the Nexus Service {#develop-caller-workflow-nexus-service} +## Develop a caller Workflow that uses the Nexus Service {/* #develop-caller-workflow-nexus-service */} Import the Service API package that has the necessary service and operation names and input/output types to execute a Nexus Operation from the caller Workflow: @@ -419,7 +419,7 @@ async Task ExecuteCallerWorkflowAsync() } ``` -## Make Nexus calls across Namespaces with a development Server {#nexus-calls-across-namespaces-dev-server} +## Make Nexus calls across Namespaces with a development Server {/* #nexus-calls-across-namespaces-dev-server */} Follow the steps below to run the Nexus handler Worker, the Nexus caller Worker, and the starter app. @@ -449,7 +449,7 @@ dotnet run caller-workflow This will show the two workflows started and their results. -### Canceling a Nexus Operation {#canceling-a-nexus-operation} +### Canceling a Nexus Operation {/* #canceling-a-nexus-operation */} To cancel a Nexus Operation from within a Workflow, cancel the cancellation token passed to the operation call. Only asynchronous operations can be canceled in Nexus, since cancellation is sent using an operation token. The Workflow or other resources backing the operation may choose to ignore the cancellation request. @@ -470,7 +470,7 @@ To ensure cancellations are delivered, wait for all pending operations to finish See the [Nexus cancellation sample](https://github.com/temporalio/samples-dotnet/tree/main/src/NexusCancellation) for reference. -## Make Nexus calls across Namespaces in Temporal Cloud {#nexus-calls-across-namespaces-temporal-cloud} +## 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. 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. diff --git a/docs/develop/dotnet/platform/observability.mdx b/docs/develop/dotnet/platform/observability.mdx index 4de025eb78..ebae810cf3 100644 --- a/docs/develop/dotnet/platform/observability.mdx +++ b/docs/develop/dotnet/platform/observability.mdx @@ -35,7 +35,7 @@ This page covers features related to viewing the state of the application, inclu The observability feature guide covers the many ways to view the current state of your [Temporal Application](/temporal#temporal-application). This includes the ways to view which [Workflow Executions](/workflow-execution) are tracked by the [Temporal Platform](/temporal#temporal-platform) and the state of any specified Workflow Execution, either currently or at points of an execution. -## Emit metrics {#metrics} +## Emit metrics {/* #metrics */} Each Temporal SDK is capable of emitting an optional set of metrics from either the Client or the Worker process. For a complete list of metrics capable of being emitted, see the [SDK metrics reference](/references/sdk-metrics). @@ -87,7 +87,7 @@ var runtime = new TemporalRuntime(new() var client = await Temporalio.ConnectAsync(new("localhost:7233") { Runtime = runtime }); ``` -## Setup Tracing {#tracing} +## Setup Tracing {/* #tracing */} Tracing allows you to view the call graph of a Workflow along with its Activities, Nexus Operations, and any Child Workflows. @@ -98,7 +98,7 @@ The [`Temporalio.Extensions.OpenTelemetry.TracingInterceptor`](https://dotnet.te When your Client is connected, spans are created for all Client calls, Activities, and Workflow invocations on the Worker. Spans are created and serialized through the server to give one trace for a Workflow Execution. -## Log from a Workflow {#logging} +## Log from a Workflow {/* #logging */} Logging enables you to record critical information during code execution. Loggers create an audit trail and capture information about your Workflow's operation. @@ -138,11 +138,11 @@ You can log from a Workflow using `Workflow.Logger` which is an instance of .NET Workflow.Logger.LogInformation("Given name: {Name}", name); ``` -## Use Visibility APIs {#visibility} +## Use Visibility APIs {/* #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 Temporal Service. -### Use Search Attributes {#search-attributes} +### Use Search Attributes {/* #search-attributes */} The typical method of retrieving a Workflow Execution is by its Workflow Id. @@ -169,7 +169,7 @@ The steps to using custom Search Attributes are: - [In the Temporal CLI](/cli/operator#list-2) - In code by calling `ListWorkflowsAsync`. -### List Workflow Executions {#list-workflow-executions} +### List Workflow Executions {/* #list-workflow-executions */} Use the [ListWorkflowsAsync()](https://dotnet.temporal.io/api/Temporalio.Client.ITemporalClient.html#Temporalio_Client_ITemporalClient_ListWorkflowsAsync_System_String_Temporalio_Client_WorkflowListOptions_) method on the Client and pass a [List Filter](/list-filter) as an argument to filter the listed Workflows. The result is an async enumerable. @@ -181,7 +181,7 @@ await foreach (var wf in client.ListWorkflowsAsync("WorkflowType='GreetingWorkfl } ``` -### Set Custom Search Attributes {#custom-search-attributes} +### Set Custom Search Attributes {/* #custom-search-attributes */} After you've created custom Search Attributes in your Temporal Service (using `temporal operator search-attribute create`or the Cloud UI), you can set the values of the custom Search Attributes when starting a Workflow. @@ -204,7 +204,7 @@ var handle = await client.StartWorkflowAsync( }); ``` -### Upsert Search Attributes {#upsert-search-attributes} +### Upsert Search Attributes {/* #upsert-search-attributes */} You can upsert Search Attributes to add, update, or remove Search Attributes from within Workflow code. diff --git a/docs/develop/dotnet/workers/interceptors.mdx b/docs/develop/dotnet/workers/interceptors.mdx index e3566c8cd8..5817ac5d2e 100644 --- a/docs/develop/dotnet/workers/interceptors.mdx +++ b/docs/develop/dotnet/workers/interceptors.mdx @@ -42,7 +42,7 @@ Activity and Client interceptors are not affected by replay. ::: -## Register an Interceptor {#register} +## Register an Interceptor {/* #register */} Registering an interceptor means supplying an interceptor instance to the SDK so Temporal can invoke it when matching Client or Worker calls occur. Once registered, the interceptor runs as part of the call path and can observe or modify diff --git a/docs/develop/dotnet/workflows/basics.mdx b/docs/develop/dotnet/workflows/basics.mdx index 9c77541090..b2e9d7a2b4 100644 --- a/docs/develop/dotnet/workflows/basics.mdx +++ b/docs/develop/dotnet/workflows/basics.mdx @@ -11,7 +11,7 @@ tags: - Temporal SDKs --- -## Develop a Workflow {#develop-workflow} +## Develop a Workflow {/* #develop-workflow */} Workflows are the fundamental unit of a Temporal Application, and it all starts with the development of a [Workflow Definition](/workflow-definition). @@ -42,7 +42,7 @@ 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. -## Workflow logic requirements {#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. @@ -141,7 +141,7 @@ dotnet_diagnostic.CS1998.severity = none dotnet_diagnostic.VSTHRD105.severity = none ``` -### Customize Workflow Type {#workflow-type} +### Customize Workflow Type {/* #workflow-type */} Workflows have a Type that are referred to as the Workflow name. diff --git a/docs/develop/dotnet/workflows/cancellation.mdx b/docs/develop/dotnet/workflows/cancellation.mdx index 5407d5638c..0bb2d03f75 100644 --- a/docs/develop/dotnet/workflows/cancellation.mdx +++ b/docs/develop/dotnet/workflows/cancellation.mdx @@ -51,7 +51,7 @@ Terminating a Workflow forcefully stops Workflow Execution. This action resemble In most cases, canceling is preferable because it allows the Workflow to finish gracefully. Terminate only if the Workflow is stuck and cannot be canceled normally. -## Cancellation {#cancellation} +## Cancellation {/* #cancellation */} To give a Workflow and its Activities the ability to be cancelled, do the following: @@ -60,7 +60,7 @@ To give a Workflow and its Activities the ability to be cancelled, do the follow - Listen for and handle a Cancellation request within an Activity. - Send a Cancellation request from a Temporal Client. -### Handle Cancellation in Workflow {#handle-cancellation-in-workflow} +### Handle Cancellation in Workflow {/* #handle-cancellation-in-workflow */} Workflow Definitions can be written to respond to cancellation requests. It is common for an Activity to be run on Cancellation to perform cleanup. @@ -110,7 +110,7 @@ public async Task RunAsync() } ``` -### Handle Cancellation in an Activity {#handle-cancellation-in-an-activity} +### Handle Cancellation in an Activity {/* #handle-cancellation-in-an-activity */} Ensure that the Activity is [Heartbeating](/develop/dotnet/activities/timeouts#activity-heartbeats) to receive the Cancellation request and stop execution. Also make sure that the @@ -134,7 +134,7 @@ public async Task MyActivityAsync() } ``` -### Request Cancellation {#request-cancellation} +### Request Cancellation {/* #request-cancellation */} Use `CancelAsync` on the `WorkflowHandle` to cancel a Workflow Execution. @@ -183,7 +183,7 @@ public async Task RunAsync() } ``` -## Termination {#termination} +## Termination {/* #termination */} To Terminate a Workflow Execution in .NET, use the [TerminateAsync()](https://dotnet.temporal.io/api/Temporalio.Client.WorkflowHandle.html#Temporalio_Client_WorkflowHandle_TerminateAsync_System_String_Temporalio_Client_WorkflowTerminateOptions_) @@ -201,7 +201,7 @@ await handle.TerminateAsync(); Workflow Executions can also be Terminated directly from the WebUI. In this case, a custom note can be logged from the UI when that happens. -## Reset a Workflow Execution {#reset} +## Reset a Workflow Execution {/* #reset */} Resetting a Workflow Execution terminates the current Workflow Execution and starts a new Workflow Execution from a point you specify in its Event History. Use reset when a Workflow is blocked due to a non-deterministic error or other diff --git a/docs/develop/dotnet/workflows/child-workflows.mdx b/docs/develop/dotnet/workflows/child-workflows.mdx index 284a6f2d7f..be1f25358c 100644 --- a/docs/develop/dotnet/workflows/child-workflows.mdx +++ b/docs/develop/dotnet/workflows/child-workflows.mdx @@ -34,7 +34,7 @@ This page shows how to do the following: - [Start a Child Workflow Execution](#child-workflows) - [Set a Parent Close Policy](#parent-close-policy) -## Start a Child Workflow Execution {#child-workflows} +## Start a Child Workflow Execution {/* #child-workflows */} A [Child Workflow Execution](/child-workflows) is a Workflow Execution that is scheduled from within another Workflow using a Child Workflow API. @@ -58,7 +58,7 @@ This is useful if you want to do something after it has only started, or to get await Workflow.ExecuteChildWorkflowAsync((MyChildWorkflow wf) => wf.RunAsync()); ``` -## Set a Parent Close Policy {#parent-close-policy} +## Set a Parent Close Policy {/* #parent-close-policy */} A [Parent Close Policy](/parent-close-policy) determines what happens to a Child Workflow Execution if its Parent changes to a Closed status (Completed, Failed, or Timed Out). diff --git a/docs/develop/dotnet/workflows/continue-as-new.mdx b/docs/develop/dotnet/workflows/continue-as-new.mdx index dbcb3a1a0a..5244e05b84 100644 --- a/docs/develop/dotnet/workflows/continue-as-new.mdx +++ b/docs/develop/dotnet/workflows/continue-as-new.mdx @@ -24,7 +24,7 @@ This page answers the following questions for .NET developers: - [When is it right to Continue-as-New?](#when) - [How to test Continue-as-New?](#how-to-test) -## What is Continue-As-New? {#what} +## What is Continue-As-New? {/* #what */} [Continue-As-New](/workflow-execution/continue-as-new) lets a Workflow Execution close successfully and creates a new Workflow Execution. You can think of it as a checkpoint when your Workflow gets too long or approaches certain scaling limits. @@ -32,7 +32,7 @@ You can think of it as a checkpoint when your Workflow gets too long or approach The new Workflow Execution is in the same [chain](/workflow-execution#workflow-execution-chain); it keeps the same Workflow Id but gets a new Run Id and a fresh Event History. It also receives your Workflow's usual parameters. -## How to Continue-As-New using the .NET SDK {#how} +## How to Continue-As-New using the .NET SDK {/* #how */} First, design your Workflow parameters so that you can pass in the "current state" when you Continue-As-New into the next Workflow run. This state is typically set to `None` for the original caller of the Workflow. @@ -74,20 +74,20 @@ throw Workflow.CreateContinueAsNewException((ClusterManagerWorkflow wf) => wf.Ru })); ```` -### Considerations for Workflows with Message Handlers {#with-message-handlers} +### Considerations for Workflows with Message Handlers {/* #with-message-handlers */} If you use Updates or Signals, don't call Continue-as-New from the handlers. Instead, wait for your handlers to finish in your main Workflow before you throw `CreateContinueAsNewException`. See the [`AllHandlersFinished`](message-passing#wait-for-message-handlers) example for guidance. -## When is it right to Continue-as-New using the .NET SDK? {#when} +## When is it right to Continue-as-New using the .NET SDK? {/* #when */} Use Continue-as-New when your Workflow might hit [Event History Limits](/workflow-execution/event#event-history). Temporal tracks your Workflow's progress against these limits to let you know when you should Continue-as-New. Call `Workflow.ContinueAsNewSuggested` to check if it's time. -## How to test Continue-as-New using the .NET SDK {#how-to-test} +## How to test Continue-as-New using the .NET SDK {/* #how-to-test */} Testing Workflows that naturally Continue-as-New may be time-consuming and resource-intensive. Instead, add a test hook to check your Workflow's Continue-as-New behavior faster in automated tests. diff --git a/docs/develop/dotnet/workflows/dynamic-workflow.mdx b/docs/develop/dotnet/workflows/dynamic-workflow.mdx index 3d07a4828b..cdf3a2ccd1 100644 --- a/docs/develop/dotnet/workflows/dynamic-workflow.mdx +++ b/docs/develop/dotnet/workflows/dynamic-workflow.mdx @@ -11,7 +11,7 @@ tags: - Temporal SDKs --- -## Set a Dynamic Workflow {#set-a-dynamic-workflow} +## Set a Dynamic Workflow {/* #set-a-dynamic-workflow */} **How to set a Dynamic Workflow using the Temporal .NET SDK** diff --git a/docs/develop/dotnet/workflows/message-passing.mdx b/docs/develop/dotnet/workflows/message-passing.mdx index 9e259aa4c9..c0cb49cf85 100644 --- a/docs/develop/dotnet/workflows/message-passing.mdx +++ b/docs/develop/dotnet/workflows/message-passing.mdx @@ -27,7 +27,7 @@ Temporal Clients use messages to read Workflow state and control execution. See [Workflow message passing](/encyclopedia/workflow-message-passing) for a general overview of this topic. This page introduces these features for the Temporal .NET SDK. -## Write message handlers {#writing-message-handlers} +## Write message handlers {/* #writing-message-handlers */} :::info The code that follows is part of a [working solution](https://github.com/temporalio/samples-dotnet/tree/main/src/MessagePassing). @@ -39,7 +39,7 @@ Follow these guidelines when writing your message handlers: - The parameters and return values of handlers and the main Workflow function must be [serializable](/dataconversion). - Prefer data classes to multiple input parameters. Data class parameters allow you to add fields without changing the calling signature. Keep in mind that serialization and deserialization can fail with the default data converter if the new field does not have a default value. -### Query handlers {#queries} +### Query handlers {/* #queries */} A [Query](/sending-messages#sending-queries) is a synchronous operation that retrieves state from a Workflow Execution. Define as a method: @@ -98,7 +98,7 @@ public class GreetingWorkflow - A Query handler must not modify Workflow state. - You can't perform async blocking operations such as executing an Activity in a Query handler. -### Signal handlers {#signals} +### Signal handlers {/* #signals */} A [Signal](/sending-messages#sending-signals) is an asynchronous message sent to a running Workflow Execution to change its state and control its flow: @@ -130,7 +130,7 @@ public class GreetingWorkflow This allows you to use Activities, Child Workflows, durable [`Workflow.DelayAsync`](https://dotnet.temporal.io/api/Temporalio.Workflows.Workflow.html?#Temporalio_Workflows_Workflow_DelayAsync_System_Int32_System_Nullable_System_Threading_CancellationToken__) Timers, [`Workflow.WaitConditionAsync`](https://dotnet.temporal.io/api/Temporalio.Workflows.Workflow.html?#Temporalio_Workflows_Workflow_WaitConditionAsync_System_Func_System_Boolean__System_Int32_System_Nullable_System_Threading_CancellationToken__) conditions, and more. See [Async handlers](#async-handlers) and [Workflow message passing](/encyclopedia/workflow-message-passing) for guidelines on safely using async Signal and Update handlers. -### Update handlers and validators {#updates} +### Update handlers and validators {/* #updates */} An [Update](/sending-messages#sending-updates) is a trackable synchronous request sent to a running Workflow Execution. It can change the Workflow state, control its flow, and return a result. @@ -196,7 +196,7 @@ public class GreetingWorkflow This allows you to use Activities, Child Workflows, durable [`Workflow.DelayAsync`](https://dotnet.temporal.io/api/Temporalio.Workflows.Workflow.html?#Temporalio_Workflows_Workflow_DelayAsync_System_Int32_System_Nullable_System_Threading_CancellationToken__) Timers, [`Workflow.WaitConditionAsync`](https://dotnet.temporal.io/api/Temporalio.Workflows.Workflow.html?#Temporalio_Workflows_Workflow_WaitConditionAsync_System_Func_System_Boolean__System_Int32_System_Nullable_System_Threading_CancellationToken__) conditions, and more. See [Async handlers](#async-handlers) and [Workflow message passing](/encyclopedia/workflow-message-passing) for guidelines on safely using async Update and Signal handlers. -## Send messages {#send-messages} +## Send messages {/* #send-messages */} To send Queries, Signals, or Updates you call methods on a [`WorkflowHandle`](https://dotnet.temporal.io/api/Temporalio.Client.WorkflowHandle.html) object. To obtain the WorkflowStub, you can: @@ -223,7 +223,7 @@ To check the argument types required when sending messages -- and the return typ ::: -### Send a Query {#send-query} +### Send a Query {/* #send-query */} Call a Query method with [`WorkflowHandle.QueryAsync`](https://dotnet.temporal.io/api/Temporalio.Client.WorkflowHandle.html#Temporalio_Client_WorkflowHandle_QueryAsync__1_System_String_System_Collections_Generic_IReadOnlyCollection_System_Object__Temporalio_Client_WorkflowQueryOptions_): @@ -239,12 +239,12 @@ var supportedLanguages = await workflowHandle.QueryAsync(wf => wf.GetLanguages(n - A Worker must be online and polling the Task Queue to process a Query. -### Send a Signal {#send-signal} +### Send a Signal {/* #send-signal */} You can send a Signal to a Workflow Execution from a Temporal Client or from another Workflow Execution. However, you can only send Signals to Workflow Executions that haven’t closed. -#### Send a Signal from a Client {#send-signal-from-client} +#### Send a Signal from a Client {/* #send-signal-from-client */} Use [`WorkflowHandle.SignalAsync`](https://dotnet.temporal.io/api/Temporalio.Client.WorkflowHandle.html#Temporalio_Client_WorkflowHandle_SignalAsync_System_String_System_Collections_Generic_IReadOnlyCollection_System_Object__Temporalio_Client_WorkflowSignalOptions_) from Client code to send a Signal: @@ -256,7 +256,7 @@ await workflowHandle.SignalAsync(wf => wf.ApproveAsync(new("MyUser"))); - The [WorkflowExecutionSignaled](/references/events#workflowexecutionsignaled) Event appears in the Workflow's Event History. -#### Send a Signal from a Workflow {#send-signal-from-workflow} +#### Send a Signal from a Workflow {/* #send-signal-from-workflow */} A Workflow can send a Signal to another Workflow, known as an _External Signal_. In this case you need to obtain a Workflow handle for the external Workflow. @@ -283,7 +283,7 @@ When an External Signal is sent: - A [SignalExternalWorkflowExecutionInitiated](/references/events#signalexternalworkflowexecutioninitiated) Event appears in the sender's Event History. - A [WorkflowExecutionSignaled](/references/events#workflowexecutionsignaled) Event appears in the recipient's Event History. -#### Signal-With-Start {#signal-with-start} +#### Signal-With-Start {/* #signal-with-start */} Signal-With-Start allows a Client to send a Signal to a Workflow Execution, starting the Execution if it is not already running. If there's a Workflow running with the given Workflow Id, it will be signaled. @@ -297,7 +297,7 @@ options.SignalWithStart((GreetingWorkflow wf) => wf.SubmitGreetingAsync("User Si await client.StartWorkflowAsync((GreetingWorkflow wf) => wf.RunAsync(), options); ``` -### Send an Update {#send-update-from-client} +### Send an Update {/* #send-update-from-client */} An Update is a synchronous, blocking call that can change Workflow state, control its flow, and return a result. @@ -339,7 +339,7 @@ To send an Update to a Workflow Execution, you can: For more details, see the "Async handlers" section. -#### Update-with-Start {#update-with-start} +#### Update-with-Start {/* #update-with-start */} :::tip @@ -416,7 +416,7 @@ Use non-type safe overloads of these APIs: ::: -## Message handler patterns {#message-handler-patterns} +## Message handler patterns {/* #message-handler-patterns */} This section covers common write operations, such as Signal and Update handlers. It doesn't apply to pure read operations, like Queries or Update Validators. @@ -427,7 +427,7 @@ For additional information, see [Inject work into the main Workflow](/handling-m ::: -### Add async handlers to use `await` {#async-handlers} +### Add async handlers to use `await` {/* #async-handlers */} Signal and Update handlers can be asynchronous as well as blocking. Using asynchronous calls allows you to `await` Activities, Child Workflows, [`Workflow.DelayAsync`](https://dotnet.temporal.io/api/Temporalio.Workflows.Workflow.html?#Temporalio_Workflows_Workflow_DelayAsync_System_Int32_System_Nullable_System_Threading_CancellationToken__) Timers, [`Workflow.WaitConditionAsync`](https://dotnet.temporal.io/api/Temporalio.Workflows.Workflow.html?#Temporalio_Workflows_Workflow_WaitConditionAsync_System_Func_System_Boolean__System_Int32_System_Nullable_System_Threading_CancellationToken__) wait conditions, etc. @@ -510,7 +510,7 @@ After updating the code for asynchronous calls, your Update handler can schedule Although an async Signal handler can initiate similar network tasks, using an Update handler allows the Client to receive a result or error once the Activity completes. This lets your Client track the progress of asynchronous work performed by the Update's Activities, Child Workflows, etc. -### Add wait conditions to block {#block-with-wait} +### Add wait conditions to block {/* #block-with-wait */} Sometimes, async Signal or Update handlers need to meet certain conditions before they should continue. Using a wait condition with [`Workflow.WaitConditionAsync`](https://dotnet.temporal.io/api/Temporalio.Workflows.Workflow.html?#Temporalio_Workflows_Workflow_WaitConditionAsync_System_Func_System_Boolean__System_Int32_System_Nullable_System_Threading_CancellationToken__) sets a function that prevents the code from proceeding until the condition returns `true`. @@ -524,7 +524,7 @@ Here are two important use cases for `Workflow.WaitConditionAsync`: The condition state you're waiting for can be updated by and reflect any part of the Workflow code. This includes the main Workflow method, other handlers, or child coroutines spawned by the main Workflow method, and so forth. -#### Use wait conditions in handlers {#wait-in-handlers} +#### Use wait conditions in handlers {/* #wait-in-handlers */} Sometimes, async Signal or Update handlers need to meet certain conditions before they should continue. Using a wait condition with [`Workflow.WaitConditionAsync`](https://dotnet.temporal.io/api/Temporalio.Workflows.Workflow.html?#Temporalio_Workflows_Workflow_WaitConditionAsync_System_Func_System_Boolean__System_Int32_System_Nullable_System_Threading_CancellationToken__) sets a function that prevents the code from proceeding until the condition returns `true`. @@ -544,7 +544,7 @@ public async Task MyUpdateAsync(UpdateInput updateInput) Remember: Handlers can execute before the main Workflow method starts. -#### Ensure your handlers finish before the Workflow completes {#wait-for-message-handlers} +#### Ensure your handlers finish before the Workflow completes {/* #wait-for-message-handlers */} Workflow wait conditions can ensure your handler completes before a Workflow finishes. When your Workflow uses async Signal or Update handlers, your main Workflow method can return or continue-as-new while a handler is still waiting on an async task, such as an Activity result. @@ -622,7 +622,7 @@ public class WorkflowInitWorkflow } ``` -### Use locks to prevent concurrent handler execution {#control-handler-concurrency} +### Use locks to prevent concurrent handler execution {/* #control-handler-concurrency */} Concurrent processes can interact in unpredictable ways. Incorrectly written [concurrent message-passing](/handling-messages#message-handler-concurrency) code may not work correctly when multiple handler instances run simultaneously. @@ -686,7 +686,7 @@ public class MyWorkflow For additional concurrency options, you can use [`Workflows.Semaphore`](https://dotnet.temporal.io/api/Temporalio.Workflows.Semaphore.html). Semaphores manage access to shared resources and coordinate the order in which threads or processes execute. -## Message handler troubleshooting {#message-handler-troubleshooting} +## Message handler troubleshooting {/* #message-handler-troubleshooting */} When sending a Signal, Update, or Query to a Workflow, your Client might encounter the following errors: @@ -698,7 +698,7 @@ When sending a Signal, Update, or Query to a Workflow, your Client might encount See [Exceptions in message handlers](/handling-messages#exceptions) for a non–.NET-specific discussion of this topic. -### Problems when sending a Signal {#signal-problems} +### Problems when sending a Signal {/* #signal-problems */} When using Signal, the only exception that will result from your requests during its execution is `RpcException`. All handlers may experience additional exceptions during the initial (pre-Worker) part of a handler request lifecycle. @@ -706,7 +706,7 @@ All handlers may experience additional exceptions during the initial (pre-Worker For Queries and Updates, the Client waits for a response from the Worker. If an issue occurs during the handler Execution by the Worker, the Client may receive an exception. -### Problems when sending an Update {#update-problems} +### Problems when sending an Update {/* #update-problems */} When working with Updates, you may encounter these errors: @@ -746,7 +746,7 @@ When working with Updates, you may encounter these errors: - The Workflow completed normally or continued-as-new and the Workflow author did not [wait for handlers to be finished](/handling-messages#finishing-message-handlers). -### Problems when sending a Query {#query-problems} +### Problems when sending a Query {/* #query-problems */} When working with Queries, you may encounter these errors: @@ -761,7 +761,7 @@ When working with Queries, you may encounter these errors: - **The handler caused the Workflow Task to fail.** This would happen, for example, if the Query handler blocks the thread for too long without yielding. -## Dynamic Handler {#dynamic-handler} +## Dynamic Handler {/* #dynamic-handler */} Temporal supports Dynamic Queries, Signals, Updates, Workflows, and Activities. These are unnamed handlers that are invoked if no other statically defined handler with the given name exists. @@ -781,7 +781,7 @@ They are meant to handle edge cases and act as a catch-all, not as the main way ::: -### Set a Dynamic Query {#set-a-dynamic-query} +### Set a Dynamic Query {/* #set-a-dynamic-query */} A Dynamic Query in Temporal is a Query method that is invoked dynamically at runtime if no other Query with the same name is registered. A Query can be made dynamic by setting `Dynamic` to `true` on the `[WorkflowQuery]` attribute. @@ -799,7 +799,7 @@ public string DynamicQueryAsync(string queryName, IRawValue[] args) } ``` -### Set a Dynamic Signal {#set-a-dynamic-signal} +### Set a Dynamic Signal {/* #set-a-dynamic-signal */} A Dynamic Signal in Temporal is a Signal that is invoked dynamically at runtime if no other Signal with the same input is registered. A Signal can be made dynamic by setting `Dynamic` to `true` on the `[WorkflowSignal]` attribute. @@ -817,7 +817,7 @@ public async Task DynamicSignalAsync(string signalName, IRawValue[] args) } ``` -### Set a Dynamic Update {#set-a-dynamic-update} +### Set a Dynamic Update {/* #set-a-dynamic-update */} A Dynamic Update in Temporal is an Update that is invoked dynamically at runtime if no other Update with the same input is registered. An Update can be made dynamic by setting `Dynamic` to `true` on the `[WorkflowUpdate]` attribute. diff --git a/docs/develop/dotnet/workflows/schedules.mdx b/docs/develop/dotnet/workflows/schedules.mdx index 3ff47c9be0..daacab9887 100644 --- a/docs/develop/dotnet/workflows/schedules.mdx +++ b/docs/develop/dotnet/workflows/schedules.mdx @@ -27,13 +27,13 @@ This page shows how to do the following: - [Update a Scheduled Workflow](#update-a-scheduled-workflow) - [Use Start Delay](#start-delay) -## Schedule a Workflow {#schedule-a-workflow} +## Schedule a Workflow {/* #schedule-a-workflow */} 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 actions to help Schedule a Workflow Execution and take control over your automation process. -### Create a Scheduled Workflow {#create-a-workflow} +### Create a Scheduled Workflow {/* #create-a-workflow */} The create action enables you to create a new Schedule. When you create a new Schedule, a unique Schedule ID is generated, which you can use to reference the Schedule in other Schedule commands. @@ -67,7 +67,7 @@ The Temporal Service doesn't guarantee when this removal will happen. ::: -### Backfill a Scheduled Workflow {#backfill-a-scheduled-workflow} +### Backfill a Scheduled Workflow {/* #backfill-a-scheduled-workflow */} The backfill action executes Actions ahead of their specified time range. This command is useful when you need to execute a missed or delayed Action, or when you want to test the Workflow before its scheduled time. @@ -91,7 +91,7 @@ await handle.BackfillAsync(new List }); ``` -### Delete a Scheduled Workflow {#delete-a-scheduled-workflow} +### Delete a Scheduled Workflow {/* #delete-a-scheduled-workflow */} The delete action enables you to delete a Schedule. When you delete a Schedule, it does not affect any Workflows that were started by the Schedule. @@ -107,7 +107,7 @@ var handle = client.GetScheduleHandle("my-schedule-id"); await handle.DeleteAsync(); ``` -### Describe a Scheduled Workflow {#describe-a-scheduled-workflow} +### Describe a Scheduled Workflow {/* #describe-a-scheduled-workflow */} The describe action shows the current Schedule configuration, including information about past, current, and future Workflow Runs. This command is helpful when you want to get a detailed view of the Schedule and its associated Workflow Runs. @@ -124,7 +124,7 @@ var desc = await handle.DescribeAsync(); Console.WriteLine("Schedule info: {0}", desc.Info); ``` -### List a Scheduled Workflow {#list-a-scheduled-workflow} +### List a Scheduled Workflow {/* #list-a-scheduled-workflow */} The list action lists all the available Schedules. This command is useful when you want to view a list of all the Schedules and their respective Schedule IDs. @@ -143,7 +143,7 @@ await foreach (var desc in client.ListSchedulesAsync()) } ``` -### Pause a Scheduled Workflow {#pause-a-scheduled-workflow} +### Pause a Scheduled Workflow {/* #pause-a-scheduled-workflow */} The pause action enables you to pause and unpause a Schedule. When you pause a Schedule, all the future Workflow Runs associated with the Schedule are temporarily stopped. This command is useful when you want to temporarily halt a Workflow due to maintenance or any other reason. @@ -160,7 +160,7 @@ var handle = client.GetScheduleHandle("my-schedule-id"); await handle.PauseAsync("Pausing the schedule for now"); ``` -### Trigger a Scheduled Workflow {#trigger-a-scheduled-workflow} +### Trigger a Scheduled Workflow {/* #trigger-a-scheduled-workflow */} The trigger action triggers an immediate action with a given Schedule. By default, this action is subject to the Overlap Policy of the Schedule. This command is helpful when you want to execute a Workflow outside of its scheduled time. @@ -176,7 +176,7 @@ var handle = client.GetScheduleHandle("my-schedule-id"); await handle.TriggerAsync(); ``` -### Update a Scheduled Workflow {#update-a-scheduled-workflow} +### Update a Scheduled Workflow {/* #update-a-scheduled-workflow */} The update action enables you to update an existing Schedule. This command is useful when you need to modify the Schedule's configuration, such as changing the start time, end time, or interval. @@ -200,7 +200,7 @@ await handle.UpdateAsync(input => }); ``` -## Use Start Delay {#start-delay} +## Use Start Delay {/* #start-delay */} Use the `StartDelay` to schedule a Workflow Execution at a specific one-time future point rather than on a recurring schedule. diff --git a/docs/develop/dotnet/workflows/timeouts.mdx b/docs/develop/dotnet/workflows/timeouts.mdx index 64cad029a2..9a38b1d8bb 100644 --- a/docs/develop/dotnet/workflows/timeouts.mdx +++ b/docs/develop/dotnet/workflows/timeouts.mdx @@ -17,7 +17,7 @@ tags: - Temporal SDKs --- -## Workflow timeouts {#workflow-timeouts} +## Workflow timeouts {/* #workflow-timeouts */} Each Workflow timeout controls the maximum duration of a different aspect of a Workflow Execution. @@ -44,7 +44,7 @@ var result = await client.ExecuteWorkflowAsync( }); ``` -### Set Workflow retries {#workflow-retries} +### Set Workflow retries {/* #workflow-retries */} A Retry Policy can work in cooperation with the timeouts to provide fine controls to optimize the execution experience. diff --git a/docs/develop/dotnet/workflows/timers.mdx b/docs/develop/dotnet/workflows/timers.mdx index 81116fe435..cdff7ca8a0 100644 --- a/docs/develop/dotnet/workflows/timers.mdx +++ b/docs/develop/dotnet/workflows/timers.mdx @@ -31,7 +31,7 @@ To add a Timer in a Workflow, use `Workflow.DelayAsync`. This is like a determin await Workflow.DelayAsync(TimeSpan.FromDays(3)); ``` - -## Develop a Nexus Service and Operation handlers {#develop-nexus-service-operation-handlers} +## Develop a Nexus Service and Operation handlers {/* #develop-nexus-service-operation-handlers */} Nexus Operation handlers are typically defined in the same Worker as the underlying Temporal primitives they abstract. Operation handlers can decide if a given Nexus Operation will be synchronous or asynchronous. @@ -310,7 +310,7 @@ func main() { ``` -## Develop a caller Workflow that uses the Nexus Service {#develop-caller-workflow-nexus-service} +## Develop a caller Workflow that uses the Nexus Service {/* #develop-caller-workflow-nexus-service */} Import the Service API package that has the necessary service and operation names and input/output types to execute a Nexus Operation from the caller Workflow: @@ -509,7 +509,7 @@ func runWorkflow(c client.Client, workflow interface{}, args ...interface{}) { ``` -## Make Nexus calls across Namespaces with a development Server {#nexus-calls-across-namespaces-dev-server} +## Make Nexus calls across Namespaces with a development Server {/* #nexus-calls-across-namespaces-dev-server */} Follow the steps below to run the Nexus handler Worker, the Nexus caller Worker, and the starter. @@ -554,7 +554,7 @@ This will result in: 2024/10/04 19:57:40 Workflow result: ¡Hola! Nexus 👋 ``` -### Canceling a Nexus Operation {#canceling-a-nexus-operation} +### Canceling a Nexus Operation {/* #canceling-a-nexus-operation */} To cancel a Nexus Operation from within a Workflow, create a Go context using the `workflow.WithCancel` API. This returns a new context and a function that, when called, cancels the context and any SDK method that was passed this context. @@ -570,7 +570,7 @@ To ensure cancelations are delivered, wait for all pending operations to finish See the [Nexus cancelation sample](https://github.com/temporalio/samples-go/tree/main/nexus-cancelation) for reference. -## Make Nexus calls across Namespaces in Temporal Cloud {#nexus-calls-across-namespaces-temporal-cloud} +## 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](/develop/go/client/temporal-client#connect-to-temporal-cloud). The same [source code](https://github.com/temporalio/samples-go/tree/main/nexus) is used in this section, but the `tcld` CLI will be 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. diff --git a/docs/develop/go/platform/observability.mdx b/docs/develop/go/platform/observability.mdx index 61387b11f3..7f858fec20 100644 --- a/docs/develop/go/platform/observability.mdx +++ b/docs/develop/go/platform/observability.mdx @@ -36,7 +36,7 @@ This section covers features related to viewing the state of the application, in - [Logging](#logging) - [Visibility](#visibility) -## How to emit metrics {#metrics} +## How to emit metrics {/* #metrics */} **How to emit application metrics using the Temporal Go SDK.** @@ -61,7 +61,7 @@ The Go SDK currently supports the [Tally](https://pkg.go.dev/go.temporal.io/sdk/ For more information, see the [Go sample for metrics](https://github.com/temporalio/samples-go/tree/main/metrics). -## Tracing {#tracing} +## Tracing {/* #tracing */} Tracing allows you to view the call graph of a Workflow along with its Activities, Nexus Operations, and Child Workflows. @@ -95,7 +95,7 @@ For more information, see the documentation for [OpenTelemetry](https://opentele To build custom context propagation (e.g., tenant IDs, auth tokens), see [Context Propagation](/develop/go/best-practices/context-propagation). -## Log from a Workflow {#logging} +## Log from a Workflow {/* #logging */} **How to log from a Workflow using the Go SDK.** @@ -152,7 +152,7 @@ workflow.WithActivityOptions(ctx, ao) } ``` -### Provide a custom logger {#custom-logger} +### Provide a custom logger {/* #custom-logger */} **How to provide a custom logger to the Temporal Client using the Go SDK.** @@ -212,11 +212,11 @@ func main() { As an alternative, you can implement the `log.Logger` interface directly. The Temporal samples repo has a [zap adapter](https://github.com/temporalio/samples-go/blob/main/zapadapter/zap_adapter.go) that can be used as a reference. -## Visibility APIs {#visibility} +## Visibility APIs {/* #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 Temporal Service. -### Search Attributes {#search-attributes} +### Search Attributes {/* #search-attributes */} **How to use Search Attributes using the Go SDK.** @@ -268,7 +268,7 @@ for _, exec := range resp.Executions { } ``` -### Set custom Search Attributes {#custom-search-attributes} +### Set custom Search Attributes {/* #custom-search-attributes */} **How to set custom Search Attributes using the Go SDK.** @@ -304,7 +304,7 @@ func (c *Client) CallYourWorkflow(ctx context.Context, workflowID string, payloa } ``` -### Upsert Search Attributes {#upsert-search-attributes} +### Upsert Search Attributes {/* #upsert-search-attributes */} **How to upsert Search Attributes using the Go SDK.** @@ -343,7 +343,7 @@ map[string]interface{}{ } ``` -### Remove a Search Attribute from a Workflow {#remove-search-attribute} +### Remove a Search Attribute from a Workflow {/* #remove-search-attribute */} **How to remove a Search Attribute from a Workflow using the Go SDK.** diff --git a/docs/develop/go/worker-versioning-legacy.mdx b/docs/develop/go/worker-versioning-legacy.mdx index 9afd2813ba..12d6bbf045 100644 --- a/docs/develop/go/worker-versioning-legacy.mdx +++ b/docs/develop/go/worker-versioning-legacy.mdx @@ -12,7 +12,7 @@ tags: - Go SDK --- -## How to use Worker Versioning in Go (Deprecated) {#worker-versioning} +## How to use Worker Versioning in Go (Deprecated) {/* #worker-versioning */} :::caution diff --git a/docs/develop/go/workers/run-worker-process.mdx b/docs/develop/go/workers/run-worker-process.mdx index ada05b1a47..310f7b68f6 100644 --- a/docs/develop/go/workers/run-worker-process.mdx +++ b/docs/develop/go/workers/run-worker-process.mdx @@ -14,7 +14,7 @@ tags: This page covers long-lived Workers that you host and run as persistent processes. For Workers that run on serverless compute like AWS Lambda, see [Serverless Workers](/develop/go/workers/serverless-workers). -## Create and run a Worker {#develop-worker} +## Create and run a Worker {/* #develop-worker */} Create a [`Worker`](https://pkg.go.dev/go.temporal.io/sdk/worker#Worker) by calling [`worker.New()`](https://pkg.go.dev/go.temporal.io/sdk/worker#New) and passing: @@ -67,12 +67,12 @@ gow run worker/main.go ::: -## Connect to Temporal Cloud {#connect-to-temporal-cloud} +## Connect to Temporal Cloud {/* #connect-to-temporal-cloud */} To run a Worker against Temporal Cloud, configure the client connection with your Namespace address and authentication credentials. See [Connect to Temporal Cloud](/develop/go/client/temporal-client#connect-to-temporal-cloud) for setup instructions. -## Register Workflows and Activities {#register-types} +## Register Workflows and Activities {/* #register-types */} All Workers listening to the same Task Queue must be registered to handle the same Workflow Types and Activity Types. If a Worker polls a Task for a type it does not know about, the Task fails. The Workflow Execution itself does not fail. @@ -89,7 +89,7 @@ w.RegisterActivity(&MyActivities{}) To customize the registered name or other options, use `RegisterWorkflowWithOptions()` or `RegisterActivityWithOptions()`. See [`workflow.RegisterOptions`](https://pkg.go.dev/go.temporal.io/sdk/workflow#RegisterOptions) and [`activity.RegisterOptions`](https://pkg.go.dev/go.temporal.io/sdk/activity#RegisterOptions). -## Worker options {#worker-options} +## Worker options {/* #worker-options */} Pass a [`worker.Options`](https://pkg.go.dev/go.temporal.io/sdk/internal#WorkerOptions) struct to `worker.New()` to configure concurrency limits, pollers, timeouts, and other Worker behavior. An empty struct uses defaults that work for most cases. diff --git a/docs/develop/go/workers/serverless-workers/aws-lambda.mdx b/docs/develop/go/workers/serverless-workers/aws-lambda.mdx index e318d950e3..ca8da50d95 100644 --- a/docs/develop/go/workers/serverless-workers/aws-lambda.mdx +++ b/docs/develop/go/workers/serverless-workers/aws-lambda.mdx @@ -35,7 +35,7 @@ You register Workflows and Activities the same way you would with a standard Wor For a full end-to-end deployment guide covering AWS IAM setup, compute configuration, and verification, see [Deploy a Serverless Worker](/production-deployment/worker-deployments/serverless-workers). -## Create and run a Worker in Lambda {#create-and-run} +## Create and run a Worker in Lambda {/* #create-and-run */} Use the `RunWorker` function to start a Lambda-based Worker. Pass a `WorkerDeploymentVersion` and a callback that registers your Workflows and Activities. @@ -81,7 +81,7 @@ Set it per-Workflow at registration time, or set a worker-level default with `De The `Options` callback gives you access to the same registration methods you use with a traditional Worker: `RegisterWorkflow`, `RegisterWorkflowWithOptions`, `RegisterActivity`, `RegisterActivityWithOptions`, and `RegisterNexusService`. -## Configure the Temporal connection {#configure-connection} +## Configure the Temporal connection {/* #configure-connection */} The `lambdaworker` package automatically loads Temporal client configuration from a TOML config file and environment variables. Refer to [Environment Configuration](/develop/environment-configuration) for more details. @@ -95,7 +95,7 @@ The file is optional. If absent, only environment variables are used. Encrypt sensitive values like TLS keys or API keys. Refer to [AWS documentation](https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars-encryption.html) for options. -## Adjust Worker defaults for Lambda {#lambda-tuned-defaults} +## Adjust Worker defaults for Lambda {/* #lambda-tuned-defaults */} The `lambdaworker` package applies conservative defaults suited to short-lived Lambda invocations. These differ from standard Worker defaults to avoid overcommitting resources in a constrained environment. @@ -125,7 +125,7 @@ The default is `WorkerStopTimeout` + 2 seconds. If your Worker handles long-running Activities, increase `WorkerStopTimeout`, `ShutdownDeadlineBuffer`, and the Lambda invocation deadline (`--timeout`) together. For guidance on how these values relate, see [Tuning for long-running Activities](/serverless-workers#tuning-for-long-running-activities). -## Add observability with OpenTelemetry {#add-observability} +## Add observability with OpenTelemetry {/* #add-observability */} The `lambdaworker/otel` sub-package provides OpenTelemetry integration with defaults configured for the [AWS Distro for OpenTelemetry (ADOT)](https://aws-otel.github.io/docs/getting-started/lambda) Lambda layer. With this enabled, the Worker emits SDK metrics and distributed traces for Workflow and Activity executions. diff --git a/docs/develop/go/workers/sessions.mdx b/docs/develop/go/workers/sessions.mdx index b3a9a3fa9c..6363e5746c 100644 --- a/docs/develop/go/workers/sessions.mdx +++ b/docs/develop/go/workers/sessions.mdx @@ -26,7 +26,7 @@ This page shows how to do the following: A Worker Session is a feature that provides a straightforward API for [Task Routing](/task-routing) to ensure that Activity Tasks are executed with the same Worker without requiring you to manually specify Task Queue names. -## Enable Worker Sessions {#enable-sessions} +## Enable Worker Sessions {/* #enable-sessions */} Set `EnableSessionWorker` to `true` in the Worker options. @@ -54,7 +54,7 @@ func main() { } ``` -### Change the maximum concurrent Sessions of a Worker. {#max-concurrent-sessions} +### Change the maximum concurrent Sessions of a Worker. {/* #max-concurrent-sessions */} You can adjust the maximum concurrent Sessions of a Worker. @@ -84,7 +84,7 @@ func main() { // ... ``` -## Create a Worker Session {#create-a-session} +## Create a Worker Session {/* #create-a-session */} Within the Workflow code use the Workflow APIs to create a Session with whichever Worker picks up the first Activity Task. @@ -155,7 +155,7 @@ func SomeFileProcessingWorkflow(ctx workflow.Context, param FileProcessingWFPara } ``` -## Additional Session usage information {#session-metadata} +## Additional Session usage information {/* #session-metadata */} ```go type SessionInfo struct { diff --git a/docs/develop/go/workflows/basics.mdx b/docs/develop/go/workflows/basics.mdx index f266e529da..9a522448ad 100644 --- a/docs/develop/go/workflows/basics.mdx +++ b/docs/develop/go/workflows/basics.mdx @@ -11,7 +11,7 @@ tags: - Temporal SDKs --- -## How to develop a basic Workflow {#develop-workflows} +## How to 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). @@ -42,7 +42,7 @@ func YourSimpleWorkflowDefinition(ctx workflow.Context) error { } ``` -### How to define Workflow parameters {#workflow-parameters} +### How to 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. @@ -90,7 +90,7 @@ func YourWorkflowDefinition(ctx workflow.Context, param YourWorkflowParam) (*You } ``` -### How to define Workflow return parameters {#workflow-return-values} +### How to define Workflow return parameters {/* #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. @@ -141,7 +141,7 @@ func YourWorkflowDefinition(ctx workflow.Context, param YourWorkflowParam) (*You } ``` -### How to customize Workflow Type in Go {#customize-workflow-type} +### How to customize Workflow Type in Go {/* #customize-workflow-type */} In Go, by default, the Workflow Type name is the same as the function name. @@ -181,7 +181,7 @@ func main() { } ``` -### How to develop Workflow logic {#workflow-logic-requirements} +### How to develop Workflow logic {/* #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. diff --git a/docs/develop/go/workflows/cancellation.mdx b/docs/develop/go/workflows/cancellation.mdx index 7a520e902f..904fd1e931 100644 --- a/docs/develop/go/workflows/cancellation.mdx +++ b/docs/develop/go/workflows/cancellation.mdx @@ -24,7 +24,7 @@ This page shows the following: - How to send a Cancellation request from a Temporal Client. - Heartbeating after a Cancellation. -## Handle Cancellation in Workflow {#handle-cancellation-in-workflow} +## Handle Cancellation in Workflow {/* #handle-cancellation-in-workflow */} Workflow Definitions can be written to handle execution cancellation requests with Go's `defer` and the `workflow.NewDisconnectedContext` API. In the Workflow Definition, there is a special Activity that handles clean up @@ -77,7 +77,7 @@ func YourWorkflow(ctx workflow.Context) error { ``` -## Handle Cancellation in an Activity {#handle-cancellation-in-an-activity} +## Handle Cancellation in an Activity {/* #handle-cancellation-in-an-activity */} **How to handle a Cancellation in an Activity in Go.** @@ -110,7 +110,7 @@ func (a *Activities) ActivityToBeCanceled(ctx context.Context) (string, error) { // ... ``` -## Request Cancellation {#request-cancellation} +## Request Cancellation {/* #request-cancellation */} **How to request Cancellation of a Workflow and Activities in Go.** @@ -148,7 +148,7 @@ When you call `activity.RecordHeartbeat` after Cancellation has occurred, a `WARN RecordActivityHeartbeat with error Error context canceled` message will be logged, and a `context canceled` error will be returned from the call. However, the Heartbeat **has** still been sent. -## Reset a Workflow Execution {#reset} +## Reset a Workflow Execution {/* #reset */} Resetting a Workflow Execution terminates the current Workflow Execution and starts a new Workflow Execution from a point you specify in its Event History. Use reset when a Workflow is blocked due to a non-deterministic error or other diff --git a/docs/develop/go/workflows/child-workflows.mdx b/docs/develop/go/workflows/child-workflows.mdx index d1a235ef0b..4f139d8199 100644 --- a/docs/develop/go/workflows/child-workflows.mdx +++ b/docs/develop/go/workflows/child-workflows.mdx @@ -18,7 +18,7 @@ This page shows how to do the following: - [Start a Child Workflow Execution](#child-workflows) - [Set a Parent Close Policy](#parent-close-policy) -## Start a Child Workflow Execution {#child-workflows} +## Start a Child Workflow Execution {/* #child-workflows */} A [Child Workflow Execution](/child-workflows) is a Workflow Execution that is scheduled from within another Workflow using a Child Workflow API. @@ -101,7 +101,7 @@ func YourOtherWorkflowDefinition(ctx workflow.Context, params ChildParams) (Chil } ``` -#### Set a Parent Close Policy {#parent-close-policy} +#### Set a Parent Close Policy {/* #parent-close-policy */} A [Parent Close Policy](/parent-close-policy) determines what happens to a Child Workflow Execution if its Parent changes to a Closed status (Completed, Failed, or Timed Out). diff --git a/docs/develop/go/workflows/continue-as-new.mdx b/docs/develop/go/workflows/continue-as-new.mdx index 18e7bcde18..4722655f95 100644 --- a/docs/develop/go/workflows/continue-as-new.mdx +++ b/docs/develop/go/workflows/continue-as-new.mdx @@ -24,7 +24,7 @@ This page answers the following questions for Go developers: - [When is it right to Continue-as-New?](#when) - [How to test Continue-as-New?](#how-to-test) -## What is Continue-As-New? {#what} +## What is Continue-As-New? {/* #what */} [Continue-As-New](/workflow-execution/continue-as-new) lets a Workflow Execution close successfully and creates a new Workflow Execution. You can think of it as a checkpoint when your Workflow gets too long or approaches certain scaling limits. @@ -32,7 +32,7 @@ You can think of it as a checkpoint when your Workflow gets too long or approach The new Workflow Execution is in the same [chain](/workflow-execution#workflow-execution-chain); it keeps the same Workflow Id but gets a new Run Id and a fresh Event History. It also receives your Workflow's usual parameters. -## How to Continue-As-New using the Go SDK {#how} +## How to Continue-As-New using the Go SDK {/* #how */} First, design your Workflow parameters so that you can pass in the "current state" when you Continue-As-New into the next Workflow run. This state is typically set to `None` for the original caller of the Workflow. @@ -74,20 +74,20 @@ return ClusterManagerResult{}, workflow.NewContinueAsNewError( ) ```` -### Considerations for Workflows with Message Handlers {#with-message-handlers} +### Considerations for Workflows with Message Handlers {/* #with-message-handlers */} If you use Updates or Signals, don't call Continue-as-New from the handlers. Instead, wait for your handlers to finish in your main Workflow before you return `NewContinueAsNewError`. See the [`AllHandlersFinished`](message-passing#wait-for-message-handlers) example for guidance. -## When is it right to Continue-as-New using the Go SDK? {#when} +## When is it right to Continue-as-New using the Go SDK? {/* #when */} Use Continue-as-New when your Workflow might hit [Event History Limits](/workflow-execution/event#event-history). Temporal tracks your Workflow's progress against these limits to let you know when you should Continue-as-New. Call `GetInfo(ctx).GetContinueAsNewSuggested()` to check if it's time. -## How to test Continue-as-New using the Go SDK {#how-to-test} +## How to test Continue-as-New using the Go SDK {/* #how-to-test */} Testing Workflows that naturally Continue-as-New may be time-consuming and resource-intensive. Instead, add a test hook to check your Workflow's Continue-as-New behavior faster in automated tests. diff --git a/docs/develop/go/workflows/dynamic-workflow.mdx b/docs/develop/go/workflows/dynamic-workflow.mdx index 0d70e8d801..894d62b19a 100644 --- a/docs/develop/go/workflows/dynamic-workflow.mdx +++ b/docs/develop/go/workflows/dynamic-workflow.mdx @@ -11,7 +11,7 @@ tags: - Temporal SDKs --- -## Set a Dynamic Workflow {#set-a-dynamic-workflow} +## Set a Dynamic Workflow {/* #set-a-dynamic-workflow */} A Dynamic Workflow in Temporal is a Workflow that is invoked dynamically at runtime if no other Workflow with the same name is registered. A Workflow can be registered as dynamic by using `worker.RegisterDynamicWorkflow()`. diff --git a/docs/develop/go/workflows/message-passing.mdx b/docs/develop/go/workflows/message-passing.mdx index a641973fc3..4c7bdf5419 100644 --- a/docs/develop/go/workflows/message-passing.mdx +++ b/docs/develop/go/workflows/message-passing.mdx @@ -32,7 +32,7 @@ Temporal Clients use messages to read Workflow state and control its execution. See [Workflow message passing](/encyclopedia/workflow-message-passing) for a general overview of this topic. This page introduces these features for the Temporal Go SDK. -## Handle messages {#handling-messages} +## Handle messages {/* #handling-messages */} :::info The code that follows is part of a working message passing [sample](https://github.com/temporalio/samples-go/tree/message-passing/message-passing-intro). @@ -44,7 +44,7 @@ Follow these guidelines when writing message handlers: - Prefer using a single struct over multiple input parameters. This allows you to add fields without changing the calling signature. -### Query handlers {#queries} +### Query handlers {/* #queries */} A [Query](/sending-messages#sending-queries) is a synchronous operation that retrieves state from a Workflow Execution: @@ -85,7 +85,7 @@ func GreetingWorkflow(ctx workflow.Context) (string, error) { - The handler must be a function that returns two values, a serializable result and an error. - You can't perform async operations such as executing an Activity in a Query handler. -### Signal Channels {#signals} +### Signal Channels {/* #signals */} A [Signal](/sending-messages#sending-signals) is an asynchronous message sent to a running Workflow Execution to change its state and control its flow. Handle Signal messages by receiving them from their channel: @@ -152,7 +152,7 @@ for { } ``` -### Update handlers and validators {#updates} +### Update handlers and validators {/* #updates */} An [Update](/sending-messages#sending-updates) is a trackable synchronous request sent to a running Workflow Execution. It can change the Workflow state, control its flow, and return a result. @@ -214,7 +214,7 @@ func GreetingWorkflow(ctx workflow.Context) error { Note that [`workflow.SetUpdateHandler`](https://pkg.go.dev/go.temporal.io/sdk/workflow#SetUpdateHandler) will immediately invoke the handler of buffered Updates with matching types. This could lead to out-of-order processing of messages with different types. -## Send messages {#send-messages} +## Send messages {/* #send-messages */} To send Queries, Signals, or Updates, you call methods on a Temporal [Client](https://pkg.go.dev/go.temporal.io/sdk/client#Client). To check the argument types required when sending messages -- and the return type for Queries and Updates -- refer to the corresponding handler method in the Workflow Definition. @@ -227,7 +227,7 @@ To check the argument types required when sending messages -- and the return typ ::: -### Send a Query {#send-query} +### Send a Query {/* #send-query */} Queries are sent from a Temporal Client. @@ -256,12 +256,12 @@ log.Println("Supported languages:", supportedLang) - A Worker must be online and polling the Task Queue to process a Query. -### Send a Signal {#send-signal} +### Send a Signal {/* #send-signal */} You can send a Signal to a Workflow Execution from a Temporal Client or from another Workflow Execution. However, you can only send Signals to Workflow Executions that haven’t closed. -#### Send a Signal from a Client {#send-signal-from-client} +#### Send a Signal from a Client {/* #send-signal-from-client */} Use [`Client.SignalWorkflow`](https://pkg.go.dev/go.temporal.io/sdk/client#Client.SignalWorkflow). @@ -281,7 +281,7 @@ if err != nil { - The [WorkflowExecutionSignaled](/references/events#workflowexecutionsignaled) Event appears in the Workflow's Event History. -#### Sending a Signal from a Workflow {#send-signal-from-workflow} +#### Sending a Signal from a Workflow {/* #send-signal-from-workflow */} A Workflow can send a Signal to another Workflow, in which case it's called an External Signal. @@ -305,7 +305,7 @@ When an External Signal is sent: - A [SignalExternalWorkflowExecutionInitiated](/references/events#signalexternalworkflowexecutioninitiated) Event appears in the sender's Event History. - A [WorkflowExecutionSignaled](/references/events#workflowexecutionsignaled) Event appears in the recipient's Event History. -#### Signal-With-Start {#signal-with-start} +#### Signal-With-Start {/* #signal-with-start */} Signal-With-Start is used from the Client. It takes a Workflow Id, Workflow arguments, a Signal name, and Signal arguments. @@ -328,7 +328,7 @@ if err != nil { } ``` -### Send an Update {#send-update-from-client} +### Send an Update {/* #send-update-from-client */} An Update is a synchronous, blocking call that can change Workflow state, control its flow, and return a result. @@ -375,7 +375,7 @@ if err != nil { } ``` -#### Update-With-Start {#update-with-start} +#### Update-With-Start {/* #update-with-start */} :::tip @@ -455,7 +455,7 @@ if err != nil { For more examples, see the [Go sample for early-return pattern](https://github.com/temporalio/samples-go/tree/main/early-return). -## Message handler patterns {#message-handler-patterns} +## Message handler patterns {/* #message-handler-patterns */} This section covers common write operations, such as Signal and Update handlers. It doesn't apply to pure read operations, like Queries or Update Validators. @@ -466,7 +466,7 @@ For additional information, see [Inject work into the main Workflow](/handling-m ::: -### Blocking handlers {#blocking-handlers} +### Blocking handlers {/* #blocking-handlers */} Signal and Update handlers can block. This allows you to use Activities, Child Workflows, durable [workflow.Sleep](https://pkg.go.dev/go.temporal.io/sdk/workflow#Sleep) Timers, [`workflow.Await`](https://pkg.go.dev/go.temporal.io/sdk/workflow#Await) conditions, etc. @@ -504,7 +504,7 @@ func GreetingWorkflow(ctx workflow.Context) error { } ``` -### Add blocking wait conditions {#block-with-wait} +### Add blocking wait conditions {/* #block-with-wait */} Sometimes, blocking Signal or Update handlers need to meet certain conditions before they should continue. You can use [`workflow.Await`](https://pkg.go.dev/go.temporal.io/sdk/workflow#Await) to prevent the code from proceeding until a condition is true. @@ -529,7 +529,7 @@ This is necessary if your Update handlers require something in the main Workflow You can also use `Workflow.await` anywhere else in the handler to wait for a specific condition to become true. This allows you to write handlers that pause at multiple points, each time waiting for a required condition to become true. -#### Ensure your handlers finish before the Workflow completes {#wait-for-message-handlers} +#### Ensure your handlers finish before the Workflow completes {/* #wait-for-message-handlers */} `Workflow.await` can ensure your handler completes before a Workflow finishes. When your Workflow uses blocking Update handlers, your main Workflow method can return or Continue-as-New while a handler is still waiting on an async task, such as an Activity. @@ -557,7 +557,7 @@ err = workflow.SetUpdateHandlerWithOptions(ctx, UpdateHandlerName, UpdateFunc, w See [Finishing handlers before the Workflow completes](/handling-messages#finishing-message-handlers) for more information. -#### Use `workflow.Mutex` to prevent concurrent handler execution {#control-handler-concurrency} +#### Use `workflow.Mutex` to prevent concurrent handler execution {/* #control-handler-concurrency */} See [Message handler concurrency](/handling-messages#message-handler-concurrency). diff --git a/docs/develop/go/workflows/schedules.mdx b/docs/develop/go/workflows/schedules.mdx index e18ae4298d..eeb4cb117c 100644 --- a/docs/develop/go/workflows/schedules.mdx +++ b/docs/develop/go/workflows/schedules.mdx @@ -27,13 +27,13 @@ This page shows how to do the following: - [Start delay](#start-delay) - [Temporal Cron Jobs](#temporal-cron-jobs) -## Scheduled Workflows {#schedule-a-workflow} +## Scheduled Workflows {/* #schedule-a-workflow */} 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 actions to help Schedule a Workflow Execution and take control over your automation process. -### Create a Schedule {#create-schedule} +### Create a Schedule {/* #create-schedule */} Schedules are initiated with the `create` call. The user generates a unique Schedule ID for each new Schedule. @@ -75,7 +75,7 @@ The Temporal Service doesn't guarantee when this removal will happen. ::: -### Backfill a Schedule {#backfill-schedule} +### Backfill a Schedule {/* #backfill-schedule */} Backfilling a Schedule executes [Workflow Tasks](/tasks#workflow-task) ahead of the Schedule's specified time range. This is useful for executing a missed or delayed Action, or for testing the Workflow ahead of time. @@ -115,7 +115,7 @@ func main() { // ... ``` -### Delete a Schedule {#delete-schedule} +### Delete a Schedule {/* #delete-schedule */} Deleting a Schedule erases a Schedule. Deletion does not affect any Workflows started by the Schedule. @@ -142,7 +142,7 @@ func main() { // ... ``` -### Describe a Schedule {#describe-schedule} +### Describe a Schedule {/* #describe-schedule */} `Describe` retrieves information about the current Schedule configuration. This can include details about the Schedule Spec (such as Intervals), CronExpressions, and Schedule State. @@ -163,7 +163,7 @@ func main() { // ... ``` -### List Schedules {#list-schedules} +### List Schedules {/* #list-schedules */} The `List` action returns all available Schedules and their respective Schedule IDs. @@ -189,7 +189,7 @@ func main() { // ... ``` -### Pause a Schedule {#pause-schedule} +### Pause a Schedule {/* #pause-schedule */} `Pause` and `Unpause` enable the start or stop of all future Workflow Runs on a given Schedule. @@ -218,7 +218,7 @@ func main() { }) ``` -### Trigger a Schedule {#trigger-schedule} +### Trigger a Schedule {/* #trigger-schedule */} Triggering a Schedule immediately executes an Action defined in that Schedule. By default, `trigger` is subject to the Overlap Policy. @@ -244,7 +244,7 @@ func main() { // ... ``` -### Update a Schedule {#update-schedule} +### Update a Schedule {/* #update-schedule */} Updating a Schedule changes the configuration of an existing Schedule. These changes can be made to Workflow Actions, Action parameters, Memos, and the Workflow's Cancellation Policy. @@ -274,7 +274,7 @@ func main() { // ... ``` -## Start Delay {#start-delay} +## Start Delay {/* #start-delay */} Use `StartDelay` to schedule a Workflow Execution at a specific one-time future point rather than on a recurring schedule. @@ -293,7 +293,7 @@ if err != nil { } ``` -## Temporal Cron Jobs {#temporal-cron-jobs} +## Temporal Cron Jobs {/* #temporal-cron-jobs */} :::caution Cron support is not recommended diff --git a/docs/develop/go/workflows/selectors.mdx b/docs/develop/go/workflows/selectors.mdx index 7e09e7cc11..76934f8fd4 100644 --- a/docs/develop/go/workflows/selectors.mdx +++ b/docs/develop/go/workflows/selectors.mdx @@ -28,7 +28,7 @@ Temporal's Go SDK `Selector`s are similar and act as a replacement. They can block on sending and receiving from Channels but as a bonus can listen on Future deferred work. Usage of Selectors to defer and process work (in place of Go's `select`) are necessary in order to ensure deterministic Workflow code execution (though using `select` in Activity code is fine). -## Full API example {#api-example} +## Full API example {/* #api-example */} The API is sufficiently different from `select` that it bears documenting: diff --git a/docs/develop/go/workflows/side-effects.mdx b/docs/develop/go/workflows/side-effects.mdx index e74cfed4ac..af39607468 100644 --- a/docs/develop/go/workflows/side-effects.mdx +++ b/docs/develop/go/workflows/side-effects.mdx @@ -67,7 +67,7 @@ workflow.SideEffect(func(ctx workflow.Context) interface{} { On replay the provided function is not executed, the random number will always be 0, and the Workflow Execution could take a different path, breaking determinism. -## Mutable Side Effects {#mutable-side-effects} +## Mutable Side Effects {/* #mutable-side-effects */} Mutable Side Effects execute the provided function once, and then it looks up the History of the value with the given Workflow ID. diff --git a/docs/develop/go/workflows/timeouts.mdx b/docs/develop/go/workflows/timeouts.mdx index f211c77399..9907894262 100644 --- a/docs/develop/go/workflows/timeouts.mdx +++ b/docs/develop/go/workflows/timeouts.mdx @@ -17,7 +17,7 @@ tags: - Temporal SDKs --- -## Workflow timeouts {#workflow-timeouts} +## Workflow timeouts {/* #workflow-timeouts */} Each Workflow timeout controls the maximum duration of a different aspect of a Workflow Execution. @@ -54,7 +54,7 @@ if err != nil { } ``` -## Workflow Retry Policy {#workflow-retries} +## Workflow Retry Policy {/* #workflow-retries */} A Retry Policy can work in cooperation with the timeouts to provide fine controls to optimize the execution experience. diff --git a/docs/develop/go/workflows/versioning.mdx b/docs/develop/go/workflows/versioning.mdx index f90e12a20a..82ec6935f5 100644 --- a/docs/develop/go/workflows/versioning.mdx +++ b/docs/develop/go/workflows/versioning.mdx @@ -36,7 +36,7 @@ Support for the experimental Worker Versioning method before 2025 will be remove Temporal's [Worker Versioning](/production-deployment/worker-deployments/worker-versioning) feature allows you to tag your Workers and programmatically roll them out in Deployment Versions, so that old Workers can run old code paths and new Workers can run new code paths. This way, you can pin your Workflows to specific revisions, avoiding the need for patching. -## Versioning with Patching {#patching} +## Versioning with Patching {/* #patching */} ### Patching with GetVersion @@ -225,7 +225,7 @@ The downside of this method is that it requires you to duplicate code and to upd This can become impractical over time. This method also does not provide a way to version any still-running Workflows -- it is essentially just a cutover, unlike Patching. -## Runtime checking {#runtime-checking} +## Runtime checking {/* #runtime-checking */} The Temporal Go SDK performs a runtime check to help prevent obvious incompatible changes. Adding, removing, or reordering any of these methods without Versioning triggers the runtime check and results in a nondeterminism error: diff --git a/docs/develop/java/activities/basics.mdx b/docs/develop/java/activities/basics.mdx index 5eb2550d94..a4880dc671 100644 --- a/docs/develop/java/activities/basics.mdx +++ b/docs/develop/java/activities/basics.mdx @@ -54,7 +54,7 @@ An Activity implementation is a Java class that implements an Activity annotated } ``` -## Define Activity parameters {#activity-parameters} +## Define Activity parameters {/* #activity-parameters */} There is no explicit limit to the total number of parameters that an [Activity Definition](/activity-definition) may support. However, there is a limit to the total size of the data that ends up encoded into a gRPC message Payload. @@ -108,7 +108,7 @@ The `execute` method in the dynamic Activity interface implementation takes in ` For more details, see [Dynamic Activity Reference](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/activity/DynamicActivity.html). -## Define Activity return values {#activity-return-values} +## Define Activity return values {/* #activity-return-values */} All data returned from an Activity must be serializable. @@ -122,7 +122,7 @@ Ensure that your Workflow or Client can handle an Object type return or is able - [Data Converter](/dataconversion) - Java DataConverter reference: [https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/common/converter/DataConverter.html](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/common/converter/DataConverter.html) -## Customize your Activity Type {#activity-type} +## Customize your Activity Type {/* #activity-type */} Each Activity has a Type, which may also be referred to as the Activity 'name'. This name appears in the Workflow Execution Event History in the Summary tab for each Activity Task. diff --git a/docs/develop/java/activities/execution.mdx b/docs/develop/java/activities/execution.mdx index 64662a8c92..4ffd598292 100644 --- a/docs/develop/java/activities/execution.mdx +++ b/docs/develop/java/activities/execution.mdx @@ -11,7 +11,7 @@ tags: - Activity --- -## Start an Activity Execution {#activity-execution} +## Start an Activity Execution {/* #activity-execution */} 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. @@ -213,7 +213,7 @@ public class FileProcessingActivitiesImpl implements FileProcessingActivities { For details on getting the results of an Activity Execution, see [Activity Execution Result](#activity-execution-result). -## Set required Activity Timeouts {#required-timeout} +## Set required Activity Timeouts {/* #required-timeout */} Activity Execution semantics rely on several parameters. The only required value that needs to be set is either a [Schedule-To-Close Timeout](/encyclopedia/detecting-activity-failures#schedule-to-close-timeout) or a [Start-To-Close Timeout](/encyclopedia/detecting-activity-failures#start-to-close-timeout). @@ -263,7 +263,7 @@ If you define options per-Activity Type options with `WorkflowImplementationOpti ::: -## Java ActivityOptions reference {#activity-options-reference} +## Java ActivityOptions reference {/* #activity-options-reference */} Use [`ActivityOptions`](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/activity/ActivityOptions.Builder.html) to configure how to invoke an Activity Execution. @@ -540,7 +540,7 @@ To set a Retry Policy, known as the [Retry Options](/encyclopedia/retry-policies .build(); ``` -## Get the result of an Activity Execution {#activity-execution-result} +## Get the result of an Activity Execution {/* #activity-execution-result */} The call to spawn an [Activity Execution](/activity-execution) generates the [ScheduleActivityTask](/references/commands#scheduleactivitytask) Command and provides the Workflow with an Awaitable. Workflow Executions can either block progress until the result is available through the Awaitable or continue progressing, making use of the result when it becomes available. diff --git a/docs/develop/java/activities/standalone-activities.mdx b/docs/develop/java/activities/standalone-activities.mdx index 6f8646eefe..be9a98c4b2 100644 --- a/docs/develop/java/activities/standalone-activities.mdx +++ b/docs/develop/java/activities/standalone-activities.mdx @@ -55,7 +55,7 @@ sample. ::: -## Get Started with Standalone Activities {#get-started} +## Get Started with Standalone Activities {/* #get-started */} Prerequisites: @@ -128,7 +128,7 @@ core/src/main/java/io/temporal/samples/standaloneactivities/ └── CountActivities.java # Counts activity executions ``` -## Define your Activity {#define-activity} +## Define your Activity {/* #define-activity */} An Activity in the Temporal Java SDK is an interface annotated with `@ActivityInterface`, with methods annotated with `@ActivityMethod`. The way you define a Standalone Activity is identical to @@ -161,7 +161,7 @@ public class GreetingActivitiesImpl implements GreetingActivities { } ``` -## Run a Worker with the Activity registered {#run-worker} +## Run a Worker with the Activity registered {/* #run-worker */} Running a Worker for Standalone Activities is the same as running a Worker for Workflow Activities — you create a `WorkerFactory`, register the Activity implementation, and call `factory.start()`. The @@ -192,7 +192,7 @@ Open a new terminal, navigate to the `samples-java` directory, and run the Worke Leave this terminal running — the Worker needs to stay up to process activities. -## Execute a Standalone Activity {#execute-activity} +## Execute a Standalone Activity {/* #execute-activity */} Use [`ActivityClient.execute()`](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/client/ActivityClient.html) @@ -259,7 +259,7 @@ Or use the Temporal CLI: --input '"World"' ``` -## Start a Standalone Activity without waiting for the result {#start-activity} +## Start a Standalone Activity without waiting for the result {/* #start-activity */} Starting a Standalone Activity means sending a request to the Temporal Server to durably enqueue your Activity job, without waiting for it to be executed by your Worker. @@ -304,7 +304,7 @@ Or use the Temporal CLI: --input '"World"' ``` -## Get a handle to an existing Standalone Activity {#get-activity-handle} +## Get a handle to an existing Standalone Activity {/* #get-activity-handle */} Use `client.getHandle()` to create a typed handle to a previously started Standalone Activity: @@ -316,7 +316,7 @@ ActivityHandle handle = Pass `null` as the run ID to target the latest run of the given activity ID. You can then use the handle to wait for the result, describe, cancel, or terminate the Activity. -## Wait for the result of a Standalone Activity {#get-activity-result} +## Wait for the result of a Standalone Activity {/* #get-activity-result */} Under the hood, calling `client.execute()` is the same as calling `client.start()` to durably enqueue the Standalone Activity, and then calling `handle.getResult()` to block until the Activity @@ -339,7 +339,7 @@ Or use the Temporal CLI to wait for a result by Activity ID: ./temporal activity result --activity-id standalone-activity-id ``` -## List Standalone Activities {#list-activities} +## List Standalone Activities {/* #list-activities */} Use [`client.listExecutions()`](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/client/ActivityClient.html) @@ -377,7 +377,7 @@ Or use the Temporal CLI: The query parameter accepts the same [List Filter](/list-filter) syntax used for [Workflow Visibility](/visibility). For example, `ActivityType = 'composeGreeting' AND Status = 'Running'`. -## Count Standalone Activities {#count-activities} +## Count Standalone Activities {/* #count-activities */} Use [`client.countExecutions()`](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/client/ActivityClient.html) @@ -408,7 +408,7 @@ Or use the Temporal CLI: ./temporal activity count ``` -## Run Standalone Activities with Temporal Cloud {#run-standalone-activities-temporal-cloud} +## Run Standalone Activities with Temporal Cloud {/* #run-standalone-activities-temporal-cloud */} The code samples on this page use `ClientConfigProfile.load()`, so the same code works against Temporal Cloud — just configure the connection via environment variables or a TOML profile. No code diff --git a/docs/develop/java/activities/timeouts.mdx b/docs/develop/java/activities/timeouts.mdx index e5b6c2be45..fa3b035160 100644 --- a/docs/develop/java/activities/timeouts.mdx +++ b/docs/develop/java/activities/timeouts.mdx @@ -68,7 +68,7 @@ If you define options per-Activity Type options with `WorkflowImplementationOpti ::: -### Custom Activity Retry Policy {#activity-retries} +### Custom Activity Retry Policy {/* #activity-retries */} A Retry Policy works in cooperation with the timeouts to provide fine controls to optimize the execution experience. @@ -115,7 +115,7 @@ To set a Retry Policy, known as the [Retry Options](/encyclopedia/retry-policies .build(); ``` -## Activity next retry delay {#activity-next-retry-delay} +## Activity next retry delay {/* #activity-next-retry-delay */} You may throw an [`ApplicationFailure`](/references/failures#application-failure) with the `NextRetryDelay` field set. This value will replace and override whatever the retry interval would be on the retry policy. @@ -131,7 +131,7 @@ throw ApplicationFailure.newFailureWithCauseAndDelay( 3 * Duration.ofSeconds(attempt)); ``` -## Heartbeat an Activity {#activity-heartbeats} +## Heartbeat an Activity {/* #activity-heartbeats */} An [Activity Heartbeat](/encyclopedia/detecting-activity-failures#activity-heartbeat) is a ping from the [Worker Process](/workers#worker-process) that is executing the Activity to the [Temporal Service](/temporal-service). Each Heartbeat informs the Temporal Service that the [Activity Execution](/activity-execution) is making progress and the Worker has not crashed. @@ -168,7 +168,7 @@ The Workflow can then use the `details` information to pass to the next Activity In the case of Activity retries, the last Heartbeat's `details` are available and can be extracted from the last failed attempt by using `Activity.getExecutionContext().getHeartbeatDetails(Class detailsClass)` -### Heartbeat Timeout {#heartbeat-timeout} +### Heartbeat Timeout {/* #heartbeat-timeout */} A [Heartbeat Timeout](/encyclopedia/detecting-activity-failures#heartbeat-timeout) works in conjunction with [Activity Heartbeats](/encyclopedia/detecting-activity-failures#activity-heartbeat). diff --git a/docs/develop/java/best-practices/converters-and-encryption.mdx b/docs/develop/java/best-practices/converters-and-encryption.mdx index 4b43119e0a..ab38db95d6 100644 --- a/docs/develop/java/best-practices/converters-and-encryption.mdx +++ b/docs/develop/java/best-practices/converters-and-encryption.mdx @@ -32,7 +32,7 @@ The server itself never adds encryption over Payloads. Therefore, unless client-side encryption is implemented, Payload data will be persisted in non-encrypted form to the data store, and any Client that can make requests to a Temporal namespace (including the Temporal UI and CLI) will be able to read Payloads contained in Workflows. When working with sensitive data, you should always implement Payload encryption. -## Custom Payload Codec in Java {#custom-payload-codec} +## Custom Payload Codec in Java {/* #custom-payload-codec */} Create a custom implementation of [`PayloadCodec`](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/payload/codec/PayloadCodec.html) and use it in [`CodecDataConverter`](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/common/converter/CodecDataConverter.html) to set a custom Data Converter. @@ -173,7 +173,7 @@ Refer to the [Codec Server](/production-deployment/data-encryption) documentatio For reference, see the [Codec server](https://github.com/temporalio/sdk-java/tree/master/temporal-remote-data-encoder) sample. -## Using custom Payload conversion {#custom-payload-conversion} +## Using custom Payload conversion {/* #custom-payload-conversion */} Temporal SDKs provide a [Payload Converter](/payload-converter) that can be customized to convert a custom data type to [Payload](/dataconversion#payload) and back. diff --git a/docs/develop/java/best-practices/debugging.mdx b/docs/develop/java/best-practices/debugging.mdx index 45e3bf398b..7391634543 100644 --- a/docs/develop/java/best-practices/debugging.mdx +++ b/docs/develop/java/best-practices/debugging.mdx @@ -30,11 +30,11 @@ Because of this you can often encounter the `PotentialDeadlockException` Excepti To alleviate this issue, you can set the `TEMPORAL_DEBUG` environment variable to true before debugging your Workflow code. Make sure to set `TEMPORAL_DEBUG` to true only during debugging. -## How to debug in a development environment {#debug-in-a-development-environment} +## How to debug in a development environment {/* #debug-in-a-development-environment */} 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 production environment {#debug-in-a-production-environment} +## How to debug in a production environment {/* #debug-in-a-production-environment */} You can debug production Workflows using: diff --git a/docs/develop/java/best-practices/testing-suite.mdx b/docs/develop/java/best-practices/testing-suite.mdx index 9a464b2998..3fa833c5f0 100644 --- a/docs/develop/java/best-practices/testing-suite.mdx +++ b/docs/develop/java/best-practices/testing-suite.mdx @@ -37,7 +37,7 @@ We generally recommend writing the majority of your tests as integration tests. Because the test server supports skipping time, use the test server for both end-to-end and integration tests with Workers. -## Test frameworks {#test-frameworks} +## Test frameworks {/* #test-frameworks */} The Temporal Java SDK provides a test framework to facilitate Workflow unit and integration testing. The test framework provides a `TestWorkflowEnvironment` class which includes an in-memory implementation @@ -239,7 +239,7 @@ public class HelloActivityJUnit5Test { You can find all unit tests for the [Temporal Java samples](https://github.com/temporalio/samples-java) repository in [its test package](https://github.com/temporalio/samples-java/tree/main/core/src/test/java/io/temporal/samples). -## Test Activities {#test-activities} +## Test Activities {/* #test-activities */} Mocking isolates code undergoing testing so the focus remains on the code, and not on external dependencies or other state. You can test Activities using a mocked Activity environment. @@ -254,12 +254,12 @@ For example, you can test an Activity for: - Exceptions thrown when checking for the result of the Activity Execution. - Activity's return values. Check that the return value matches the expected value. -### Run an Activity {#run-an-activity} +### Run an Activity {/* #run-an-activity */} During isolation testing, if an Activity references its context, you'll need to mock that context. Mocked information stands in for the context, allowing you to focus your testing on the Activity's code. -### Listen to Heartbeats {#listen-to-heartbeats} +### Listen to Heartbeats {/* #listen-to-heartbeats */} Activities usually issue periodic Heartbeats, a feature that broadcasts recurring proof-of-life updates. Each ping shows that an Activity is making progress and the Worker hasn't crashed. @@ -269,20 +269,20 @@ When testing Activities that support Heartbeats, make sure you can see those Hea Provide appropriate test coverage. This enables you to verify both the Heartbeat's content and behavior. -### Cancel an Activity {#cancel-an-activity} +### Cancel an Activity {/* #cancel-an-activity */} Activity cancellation lets Activities know they don't need to continue work and gives time for the Activity to clean up any resources it's created. You can cancel Java-based activities if they emit Heartbeats. To test an Activity that reacts to Cancellations, make sure that the Activity reacts correctly and cancels. -## Testing Workflows {#test-workflows} +## Testing Workflows {/* #test-workflows */} -### How to mock Activities {#mock-activities} +### How to mock Activities {/* #mock-activities */} Mock the Activity invocation when unit testing your Workflows. When integration testing Workflows with a Worker, you can mock Activities by providing mock Activity implementations to the Worker. For more details on mocking activities, see [sample unit tests](#sample-unit-tests). -### How to mock Nexus Operations {#mock-nexus-operations} +### How to mock Nexus Operations {/* #mock-nexus-operations */} When integration testing Workflows with a Worker, you can mock Nexus operations by providing mock Nexus Service handlers to the Worker. Alternatively, you could just mock the Nexus service itself. @@ -513,7 +513,7 @@ public class NexusServiceJunit5Test { ``` -### How to skip time {#skip-time} +### How to skip time {/* #skip-time */} Some long-running Workflows can persist for months or even years. Implementing the test framework allows your Workflow code to skip time and complete your tests in seconds rather than the Workflow's specified amount. @@ -526,21 +526,21 @@ Time is a global property of an instance of `TestWorkflowEnvironment`: skipping If you need different time behaviors for different tests, run your tests in a series or with separate instances of the test server. For example, you could run all tests with automatic time skipping in parallel, and then all tests with manual time skipping in series, and then all tests without time skipping in parallel. -#### Set up time skipping {#setting-up} +#### Set up time skipping {/* #setting-up */} Set up the time-skipping test framework in the SDK of your choice. -{/* #### Skip time automatically {#automatic-method} */} +{/* #### Skip time automatically {/* #automatic-method */} */} You can skip time automatically in the SDK of your choice. Start a test server process that skips time as needed. For example, in the time-skipping mode, Timers, which include sleeps and conditional timeouts, are fast-forwarded except when Activities or Nexus Operation handlers are running. Nexus Operation handlers timeout after 10 seconds and time skipping is allowed while waiting for retries. -{/* #### Skip time manually {#manual-method} */} +{/* #### Skip time manually {/* #manual-method */} */} Skip time manually in the SDK of your choice. -## How to Replay a Workflow Execution {#replay} +## How to Replay a Workflow Execution {/* #replay */} Replay recreates the exact state of a Workflow Execution. You can replay a Workflow from the beginning of its Event History. diff --git a/docs/develop/java/client/namespaces.mdx b/docs/develop/java/client/namespaces.mdx index 2a9d901354..39ba80c834 100644 --- a/docs/develop/java/client/namespaces.mdx +++ b/docs/develop/java/client/namespaces.mdx @@ -32,7 +32,7 @@ Use a custom [Authorizer](/self-hosted-guide/security#authorizer-plugin) on your You must register a Namespace with the Temporal Service before setting it in the Temporal Client. -## Register a Namespace {#register-namespace} +## Register a Namespace {/* #register-namespace */} Registering a Namespace creates a Namespace on the Temporal Service or Temporal Cloud. @@ -72,7 +72,7 @@ Ensure that you wait for this registration to complete before starting the Workf To update your Namespace use the [UpdateNamespace API](#manage-namespaces) with the NamespaceClient. -## Manage Namespaces {#manage-namespaces} +## Manage Namespaces {/* #manage-namespaces */} You can get details for your Namespaces, update Namespace configuration, and deprecate or delete your Namespaces. diff --git a/docs/develop/java/client/temporal-client.mdx b/docs/develop/java/client/temporal-client.mdx index b717ff8987..2c228699a0 100644 --- a/docs/develop/java/client/temporal-client.mdx +++ b/docs/develop/java/client/temporal-client.mdx @@ -51,7 +51,7 @@ Temporal Client inside an Activity to communicate with a Temporal Service. ::: -## Connect to a development Temporal Service {#connect-to-development-service} +## Connect to a development Temporal Service {/* #connect-to-development-service */} Use the `newLocalServiceStubs` method to create a stub that points to the Temporal development service, and then use the [`WorkflowClient.newInstance` method](https://javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/client/WorkflowClient.html#newInstance(io.temporal.serviceclient.WorkflowServiceStubs)) @@ -288,7 +288,7 @@ variables or a configuration file, and then override specific options in code. -## Connect to Temporal Cloud {#connect-to-temporal-cloud} +## Connect to Temporal Cloud {/* #connect-to-temporal-cloud */} You can connect to Temporal Cloud using either an [API key](/cloud/api-keys) or through [mTLS](/cloud/certificates). Connection to Temporal Cloud or any secured Temporal Service requires additional connection options compared to @@ -601,7 +601,7 @@ the new Client: -## Start a Workflow Execution {#start-workflow-execution} +## Start a Workflow Execution {/* #start-workflow-execution */} [Workflow Execution](/workflow-execution) semantics rely on several parameters—that is, to start a Workflow Execution you must supply a Task Queue that will be used for the Tasks (one that a Worker is polling), the Workflow Type, @@ -748,7 +748,7 @@ written in other language SDKs. You can start a Workflow Execution on a regular schedule by using [`setCronSchedule`](/develop/java/workflows/schedules#cron-schedule) Workflow option in the Client code. -### How to set a Workflow's Task Queue {#set-task-queue} +### How to set a Workflow's Task Queue {/* #set-task-queue */} In most SDKs, the only Workflow Option that must be set is the name of the [Task Queue](/task-queue). @@ -775,7 +775,7 @@ YourWorkflowInterface workflow1 = .build()); ``` -### How to set a Workflow Id {#workflow-id} +### How to set a Workflow Id {/* #workflow-id */} Although it is not required, we recommend providing your own [Workflow Id](/workflow-execution/workflowid-runid#workflow-id) that maps to a business process or business entity @@ -801,7 +801,7 @@ YourWorkflowInterface workflow1 = .build()); ``` -### Java WorkflowOptions reference {#workflow-options-reference} +### Java WorkflowOptions reference {/* #workflow-options-reference */} Create a [`newWorkflowStub`](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/client/WorkflowStub.html) in @@ -1066,7 +1066,7 @@ The following Java types are supported: - OffsetDateTime - Collection of the types in this list. -### How to get the result of a Workflow Execution in Java {#get-workflow-results} +### How to get the result of a Workflow Execution in Java {/* #get-workflow-results */} If the call to start a Workflow Execution is successful, you will gain access to the Workflow Execution's Run Id. diff --git a/docs/develop/java/integrations/spring-boot.mdx b/docs/develop/java/integrations/spring-boot.mdx index dbd736a347..ede6b4a5e2 100644 --- a/docs/develop/java/integrations/spring-boot.mdx +++ b/docs/develop/java/integrations/spring-boot.mdx @@ -25,7 +25,7 @@ This section includes the following topics: - [Integrations](#integrations) - [Testing](#testing) -## Setup Dependency {#setup-dependency} +## Setup Dependency {/* #setup-dependency */} To start using the Temporal Spring Boot integration, you need to add [`io.temporal:temporal-spring-boot-starter`](https://search.maven.org/artifact/io.temporal/temporal-spring-boot-starter) as a dependency to your Spring project: @@ -50,7 +50,7 @@ Temporal's Spring Boot integration currently supports Spring Boot 2.x, 3.x, and implementation ("io.temporal:temporal-spring-boot-starter:1.31.0") ``` -## Connect {#connect} +## Connect {/* #connect */} See the [Temporal Client documentation](/develop/java/client/temporal-client) for more information about connecting to a Temporal Service. @@ -85,7 +85,7 @@ spring.temporal: namespace: # you can specify a custom namespace that you are using ``` -## Connect to Temporal Cloud {#connect} +## Connect to Temporal Cloud {/* #connect */} You can also connect to Temporal Cloud, using either an API key or mTLS for authentication. @@ -113,7 +113,7 @@ spring.temporal: namespace: ``` -## Configure Workers {#configure-workers} +## Configure Workers {/* #configure-workers */} Temporal's Spring Boot integration supports two configuration methods for Workers: explicit configuration and auto-discovery. @@ -167,11 +167,11 @@ public class MyActivityImpl implements MyActivity { Auto-discovered Workflow implementation classes, Activity beans, and Nexus Service beans will be registered with the configured Workers if not already registered. ::: -## Interceptors {#interceptors} +## Interceptors {/* #interceptors */} To enable Interceptors, you can create beans by implementing the `io.temporal.common.interceptors.WorkflowClientInterceptor`, `io.temporal.common.interceptors.ScheduleClientInterceptor`, or `io.temporal.common.interceptors.WorkerInterceptor` interface. Interceptors will be registered in the order specified by the `@Order` annotation. -## Integrations {#integrations} +## Integrations {/* #integrations */} The Temporal Spring Boot integration also has built in support for various tools in the Spring ecosystem, such as metrics and tracing. @@ -187,7 +187,7 @@ You can set up [Spring Cloud Sleuth](https://spring.io/projects/spring-cloud-sle Alternatively, you can define a custom `io.opentelemetry.api.OpenTelemetry` for OpenTelemetry or `io.opentracing.Tracer` for an OpenTracing bean in the application context. -## Customization of Options {#customize-options} +## Customization of Options {/* #customize-options */} To programmatically customize the various options that are created by the Spring Boot integration, you can create beans that implement the `io.temporal.spring.boot.TemporalOptionsCustomizer` interface. This will be called after the options in your properties files are applied. @@ -204,7 +204,7 @@ Where `OptionsType` may be one of: `io.temporal.spring.boot.WorkflowImplementationOptionsCustomizer` may be used instead of `TemporalOptionsCustomizer` if `WorkflowImplementationOptions` needs to be customized on Workflow Type. -## Testing {#testing} +## Testing {/* #testing */} The Temporal Spring Boot integration also has easy support for testing your Temporal code. Add the following to your `application.yml` to reconfigure the client to work through `io.temporal.testing.TestWorkflowEnvironment` that uses in-memory Java Test Server: diff --git a/docs/develop/java/nexus/feature-guide.mdx b/docs/develop/java/nexus/feature-guide.mdx index eae052047e..39e75973e3 100644 --- a/docs/develop/java/nexus/feature-guide.mdx +++ b/docs/develop/java/nexus/feature-guide.mdx @@ -45,7 +45,7 @@ This documentation uses source code derived from the ::: -## Run the Temporal Development Server with Nexus enabled {#run-the-temporal-nexus-development-server} +## Run the Temporal Development Server with Nexus enabled {/* #run-the-temporal-nexus-development-server */} Prerequisites: @@ -66,7 +66,7 @@ It uses an in-memory database, so do not use it for real use cases. The Temporal Web UI should now be accessible at [http://localhost:8233](http://localhost:8233), and the Temporal Server should now be available for client connections on `localhost:7233`. -## Create caller and handler Namespaces {#create-caller-handler-namespaces} +## Create caller and handler Namespaces {/* #create-caller-handler-namespaces */} Before setting up Nexus endpoints, create separate Namespaces for the caller and handler. @@ -78,7 +78,7 @@ temporal operator namespace create --namespace my-caller-namespace `my-target-namespace` will contain the Nexus Operation handler, and we will use a Workflow in `my-caller-namespace` to call that Operation handler. We use different namespaces to demonstrate cross-Namespace Nexus calls. -## Create a Nexus Endpoint to route requests from caller to handler {#create-nexus-endpoint} +## Create a Nexus Endpoint to route requests from caller to handler {/* #create-nexus-endpoint */} After establishing caller and handler Namespaces, the next step is to create a Nexus Endpoint to route requests. @@ -91,7 +91,7 @@ temporal operator nexus endpoint create \ You can also use the Web UI to create the Namespaces and Nexus endpoint. -## Define the Nexus Service contract {#define-nexus-service-contract} +## Define the Nexus Service contract {/* #define-nexus-service-contract */} Defining a clear contract for the Nexus Service is crucial for smooth communication. @@ -192,7 +192,7 @@ public interface SampleNexusService { -## Develop a Nexus Service and Operation handlers {#develop-nexus-service-operation-handlers} +## Develop a Nexus Service and Operation handlers {/* #develop-nexus-service-operation-handlers */} Nexus Operation handlers are typically defined in the same Worker as the underlying Temporal primitives they abstract. Operation handlers can decide if a given Nexus Operation will be synchronous or asynchronous. They can invoke underlying @@ -425,7 +425,7 @@ public class HandlerWorker { -## Develop a caller Workflow that uses the Nexus Service {#develop-caller-workflow-nexus-service} +## Develop a caller Workflow that uses the Nexus Service {/* #develop-caller-workflow-nexus-service */} Import the Service API package that has the necessary service and operation names and input/output types to execute a Nexus Operation from the caller Workflow: @@ -597,7 +597,7 @@ public class CallerStarter { -## Make Nexus calls across Namespaces with a development Server {#nexus-calls-across-namespaces-dev-server} +## Make Nexus calls across Namespaces with a development Server {/* #nexus-calls-across-namespaces-dev-server */} Follow the steps below to run the Nexus handler Worker, the Nexus caller Worker, and the starter app. @@ -637,7 +637,7 @@ This will result in: [main] INFO i.t.s.nexus.caller.CallerStarter - Workflow result: ¡Hola! Nexus 👋 ``` -### Canceling a Nexus Operation {#canceling-a-nexus-operation} +### Canceling a Nexus Operation {/* #canceling-a-nexus-operation */} To cancel a Nexus Operation from within a Workflow, create a `CancellationScope` using the `Workflow.newCancellationScope` API. `Workflow.newCancellationScope` takes a `Runnable`. Any SDK methods started in this @@ -674,7 +674,7 @@ See the [Nexus cancelation sample](https://github.com/temporalio/samples-java/tree/main/core/src/main/java/io/temporal/samples/nexuscancellation) for reference. -## Make Nexus calls across Namespaces in Temporal Cloud {#nexus-calls-across-namespaces-temporal-cloud} +## Make Nexus calls across Namespaces in Temporal Cloud {/* #nexus-calls-across-namespaces-temporal-cloud */} This section assumes you are already familiar with [how connect a Worker to Temporal Cloud](/develop/java/client/temporal-client#start-workflow-execution). The same diff --git a/docs/develop/java/platform/observability.mdx b/docs/develop/java/platform/observability.mdx index 61ec2ab12d..07228e555f 100644 --- a/docs/develop/java/platform/observability.mdx +++ b/docs/develop/java/platform/observability.mdx @@ -37,7 +37,7 @@ This section covers features related to viewing the state of the application, in - [Log from a Workflow](#logging) - [Visibility APIs](#visibility) -## Emit metrics {#metrics} +## Emit metrics {/* #metrics */} Each Temporal SDK is capable of emitting an optional set of metrics from either the Client or the Worker process. For a complete list of metrics capable of being emitted, see the [SDK metrics reference](/references/sdk-metrics). @@ -72,7 +72,7 @@ The following example shows how to use `MicrometerClientStatsReporter` to define For more details, see the [Java SDK Samples](https://github.com/temporalio/samples-java/tree/637c2e66fd2dab43d9f3f39e5fd9c55e4f3884f0/core/src/main/java/io/temporal/samples/metrics). For details on configuring a Prometheus scrape endpoint with Micrometer, see the [Micrometer Prometheus Configuring](https://docs.micrometer.io/micrometer/reference/implementations/prometheus.html#_configuring) documentation. -## Set up tracing {#tracing} +## Set up tracing {/* #tracing */} Tracing allows you to view the call graph of a Workflow along with its Activities, Nexus Operations, and any Child Workflows. @@ -128,7 +128,7 @@ This map is special as it will normalize all keys to lowercase. Because Nexus uses this custom format, and because Nexus calls may involve external systems, the `ContextPropagator` interface doesn’t apply to Nexus headers. Context must be explicitly propagated through interceptors, as shown in the [Nexus Context Propagation sample](https://github.com/temporalio/samples-java/tree/main/core/src/main/java/io/temporal/samples/nexuscontextpropagation). -## Log from a Workflow {#logging} +## Log from a Workflow {/* #logging */} Logging enables you to record critical information during code execution. Loggers create an audit trail and capture information about your Workflow's operation. @@ -156,17 +156,17 @@ private static final Logger logger = Workflow.getLogger(DynamicDslWorkflow.class Logs in replay mode are omitted unless the [`WorkerFactoryOptions.Builder.setEnableLoggingInReplay(boolean)`](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/worker/WorkerFactoryOptions.Builder.html#setEnableLoggingInReplay(boolean)) method is set to true. -### How to provide a custom logger {#custom-logger} +### How to provide a custom logger {/* #custom-logger */} Use a custom logger for logging. To set a custom logger, supply your own logging implementation and configuration details the same way you would in any other Java application. -## Visibility APIs {#visibility} +## Visibility APIs {/* #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 Temporal Service. -### How to use Search Attributes {#search-attributes} +### How to use Search Attributes {/* #search-attributes */} The typical method of retrieving a Workflow Execution is by its Workflow Id. @@ -190,7 +190,7 @@ The steps to using custom Search Attributes are: - [In the Temporal CLI](/cli/workflow#list). - In code by calling `ListWorkflowExecutions`. -### How to set custom Search Attributes {#custom-search-attributes} +### How to set custom Search Attributes {/* #custom-search-attributes */} After you've created custom Search Attributes in your Temporal Service (using `temporal operator search-attribute create` or the Cloud UI), you can set the values of the custom Search Attributes when starting a Workflow. @@ -229,7 +229,7 @@ Each `SearchAttribute` object represents a custom attribute name, and the value In this example `isOrderFailed` is set as a Search Attribute. This attribute is useful for querying Workflows based on the success/failure of customer orders. -### How to upsert Search Attributes {#upsert-search-attributes} +### How to upsert Search Attributes {/* #upsert-search-attributes */} Within the Workflow code, you can dynamically add or update Search Attributes using [`upsertTypedSearchAttributes`](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/workflow/Workflow.html#upsertTypedSearchAttributes(io.temporal.common.SearchAttributeUpdate...)). This method is particularly useful for Workflows whose attributes need to change based on internal logic or external events. @@ -255,7 +255,7 @@ This method is particularly useful for Workflows whose attributes need to change } ``` -### How to remove a Search Attribute from a Workflow {#remove-search-attribute} +### How to remove a Search Attribute from a Workflow {/* #remove-search-attribute */} To remove a Search Attribute that was previously set, set it to an empty Map. diff --git a/docs/develop/java/worker-versioning-legacy.mdx b/docs/develop/java/worker-versioning-legacy.mdx index a7cd8397aa..8b49793e04 100644 --- a/docs/develop/java/worker-versioning-legacy.mdx +++ b/docs/develop/java/worker-versioning-legacy.mdx @@ -12,7 +12,7 @@ tags: - Java SDK --- -## How to use Worker Versioning in Java (Deprecated) {#worker-versioning} +## How to use Worker Versioning in Java (Deprecated) {/* #worker-versioning */} :::caution diff --git a/docs/develop/java/workers/run-process.mdx b/docs/develop/java/workers/run-process.mdx index b1dd2606a0..a19875a883 100644 --- a/docs/develop/java/workers/run-process.mdx +++ b/docs/develop/java/workers/run-process.mdx @@ -11,7 +11,7 @@ tags: - Temporal SDKs --- -## How to run Worker Processes {#run-a-dev-worker} +## How to run Worker Processes {/* #run-a-dev-worker */} The [Worker Process](/workers#worker-process) is where Workflow Functions and Activity Functions are executed. @@ -62,7 +62,7 @@ A Worker can be registered with just Workflows, just Activities, or both. - [How to tune Workers](/develop/worker-performance) -## How to register types {#register-types} +## How to register types {/* #register-types */} All Workers listening to the same Task Queue name must be registered to handle the exact same Workflows Types and Activity Types. diff --git a/docs/develop/java/workflows/basics.mdx b/docs/develop/java/workflows/basics.mdx index bc5b23b705..9ffc6fb05d 100644 --- a/docs/develop/java/workflows/basics.mdx +++ b/docs/develop/java/workflows/basics.mdx @@ -11,7 +11,7 @@ tags: - Temporal SDKs --- -## How to develop a Workflow {#develop-workflows} +## How to develop a 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). @@ -54,7 +54,7 @@ Use `ExternalWorkflowStub` to start or send Signals from within a Workflow to ot You can also invoke other Workflows as Child Workflows with `Workflow.newChildWorkflowStub()` or `Workflow.newUntypedChildWorkflowStub()` within a Workflow Definition. -## Workflow interface inheritance {#interface-inheritance} +## Workflow interface inheritance {/* #interface-inheritance */} Workflow interfaces can form inheritance hierarchies. It may be useful for creating reusable components across multiple @@ -137,7 +137,7 @@ This registration will fail with: java.lang.IllegalStateException: BaseWorkflow workflow type is already registered with the worker ``` -## 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. @@ -161,7 +161,7 @@ public interface YourWorkflow { } ``` -## Define Workflow return parameters {#workflow-return-values} +## Define Workflow return parameters {/* #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. @@ -177,7 +177,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 your Workflow Type {/* #workflow-type */} Workflows have a Type that is referred to as the Workflow name. @@ -209,7 +209,7 @@ In the following example, the Workflow Type is set to `your-workflow`. When you set the Workflow Type this way, the value of the `name` parameter does not have to start with an uppercase letter. -## Workflow logic requirements {#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 external (to the Workflow) application code. diff --git a/docs/develop/java/workflows/cancellation.mdx b/docs/develop/java/workflows/cancellation.mdx index 6527fec07d..9d524e336a 100644 --- a/docs/develop/java/workflows/cancellation.mdx +++ b/docs/develop/java/workflows/cancellation.mdx @@ -35,7 +35,7 @@ Terminating a Workflow forcefully stops Workflow Execution. This action resemble In most cases, canceling is preferable because it allows the Workflow to finish gracefully. Terminate only if the Workflow is stuck and cannot be canceled normally. -## Cancel a Workflow Execution {#cancellation} +## Cancel a Workflow Execution {/* #cancellation */} Canceling a Workflow provides a graceful way to stop Workflow Execution. This action resembles sending a `SIGTERM` to a process. @@ -54,7 +54,7 @@ WorkflowStub workflowStub = WorkflowStub.fromTyped(workflow); workflowStub.cancel(); ``` -## Cancellation scopes in Java {#cancellation-scopes} +## Cancellation scopes in Java {/* #cancellation-scopes */} In the Java SDK, Workflows are represented internally by a tree of cancellation scopes, each with cancellation behaviors you can specify. By default, everything runs in the "root" scope. @@ -84,7 +84,7 @@ created within it, such as the following: - Child Workflows - Nexus Operations -### Cancel an Activity from a Workflow {#cancel-activity} +### Cancel an Activity from a Workflow {/* #cancel-activity */} Canceling an Activity from within a Workflow requires that the Activity Execution sends Heartbeats and sets a Heartbeat Timeout. If the Heartbeat is not invoked, the Activity cannot receive a cancellation request. When any non-immediate @@ -158,7 +158,7 @@ public class GreetingWorkflowImpl implements GreetingWorkflow { } ``` -## Terminate a Workflow Execution {#termination} +## Terminate a Workflow Execution {/* #termination */} Terminating a Workflow forcefully stops Workflow Execution. This action resembles killing a process. @@ -176,7 +176,7 @@ WorkflowStub untyped = WorkflowStub.fromTyped(myWorkflowStub); untyped.terminate("Sample reason"); ``` -## Reset a Workflow Execution {#reset} +## Reset a Workflow Execution {/* #reset */} Resetting a Workflow Execution terminates the current Workflow Execution and starts a new Workflow Execution from a point you specify in its Event History. Use reset when a Workflow is blocked due to a non-deterministic error or other diff --git a/docs/develop/java/workflows/child-workflows.mdx b/docs/develop/java/workflows/child-workflows.mdx index 166fb20ebb..747a2df3b6 100644 --- a/docs/develop/java/workflows/child-workflows.mdx +++ b/docs/develop/java/workflows/child-workflows.mdx @@ -18,7 +18,7 @@ This page shows how to do the following: - [Start a Child Workflow Execution](#start-child-workflow) - [Set a Parent Close Policy](#parent-close-policy) -## Start a Child Workflow Execution {#start-child-workflow} +## Start a Child Workflow Execution {/* #start-child-workflow */} A [Child Workflow Execution](/child-workflows) is a Workflow Execution that is scheduled from within another Workflow using a Child Workflow API. @@ -141,7 +141,7 @@ Related reads: - Java Workflow reference: [https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/workflow/package-summary.html](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/workflow/package-summary.html) -## Parent Close Policy {#parent-close-policy} +## Parent Close Policy {/* #parent-close-policy */} A [Parent Close Policy](/parent-close-policy) determines what happens to a Child Workflow Execution if its Parent changes to a Closed status (Completed, Failed, or Timed Out). diff --git a/docs/develop/java/workflows/continue-as-new.mdx b/docs/develop/java/workflows/continue-as-new.mdx index 2512ecd334..783ed03232 100644 --- a/docs/develop/java/workflows/continue-as-new.mdx +++ b/docs/develop/java/workflows/continue-as-new.mdx @@ -24,7 +24,7 @@ This page answers the following questions for Java developers: - [When is it right to Continue-as-New?](#when) - [How to test Continue-as-New?](#how-to-test) -## What is Continue-As-New? {#what} +## What is Continue-As-New? {/* #what */} [Continue-As-New](/workflow-execution/continue-as-new) lets a Workflow Execution close successfully and creates a new Workflow Execution. You can think of it as a checkpoint when your Workflow gets too long or approaches certain scaling limits. @@ -32,7 +32,7 @@ You can think of it as a checkpoint when your Workflow gets too long or approach The new Workflow Execution is in the same [chain](/workflow-execution#workflow-execution-chain); it keeps the same Workflow Id but gets a new Run Id and a fresh Event History. It also receives your Workflow's usual parameters. -## How to Continue-As-New using the Java SDK {#how} +## How to Continue-As-New using the Java SDK {/* #how */} First, design your Workflow parameters so that you can pass in the "current state" when you Continue-As-New into the next Workflow run. This state is typically set to `None` for the original caller of the Workflow. @@ -69,19 +69,19 @@ Workflow.continueAsNew( new ClusterManagerInput(Optional.of(state), input.isTestContinueAsNew())); ```` -### Considerations for Workflows with Message Handlers {#with-message-handlers} +### Considerations for Workflows with Message Handlers {/* #with-message-handlers */} If you use Updates or Signals, don't call Continue-as-New from the handlers. Instead, wait for your handlers to finish in your main Workflow before you run `continueAsNew`. -## When is it right to Continue-as-New using the Java SDK? {#when} +## When is it right to Continue-as-New using the Java SDK? {/* #when */} Use Continue-as-New when your Workflow might hit [Event History Limits](/workflow-execution/event#event-history). Temporal tracks your Workflow's progress against these limits to let you know when you should Continue-as-New. Call `Workflow.getInfo().isContinueAsNewSuggested()` to check if it's time. -## How to test Continue-as-New using the Java SDK {#how-to-test} +## How to test Continue-as-New using the Java SDK {/* #how-to-test */} Testing Workflows that naturally Continue-as-New may be time-consuming and resource-intensive. Instead, add a test hook to check your Workflow's Continue-as-New behavior faster in automated tests. diff --git a/docs/develop/java/workflows/message-passing.mdx b/docs/develop/java/workflows/message-passing.mdx index ed8ba44d81..70e95bcc01 100644 --- a/docs/develop/java/workflows/message-passing.mdx +++ b/docs/develop/java/workflows/message-passing.mdx @@ -32,7 +32,7 @@ Temporal Clients use messages to read Workflow state and control execution. See [Workflow message passing](/encyclopedia/workflow-message-passing) for a general overview of this topic. This page introduces these features for the Temporal Java SDK. -## Write message handlers {#writing-message-handlers} +## Write message handlers {/* #writing-message-handlers */} Follow these guidelines when writing your message handlers: @@ -41,7 +41,7 @@ Follow these guidelines when writing your message handlers: - Prefer a single class with multiple fields over using multiple input parameters. A class allows you to add fields without changing the calling signature. -### Query handlers {#queries} +### Query handlers {/* #queries */} A [Query](/sending-messages#sending-queries) is a synchronous operation that retrieves state from a Workflow Execution: @@ -98,7 +98,7 @@ public class MessagePassingIntro { - You can't perform blocking operations such as executing an Activity in a Query handler. - The Query annotation accepts an argument (`name`) as described in the API reference docs for [`@QueryMethod`](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/workflow/QueryMethod.html). -### Signal handlers {#signals} +### Signal handlers {/* #signals */} A [Signal](/sending-messages#sending-signals) is an asynchronous message sent to a running Workflow Execution to change its state and control its flow: @@ -148,7 +148,7 @@ public class MessagePassingIntro { This allows you to use Activities, Child Workflows, durable [`Workflow.sleep`](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/workflow/Workflow.html#sleep(java.time.Duration)) Timers, [`Workflow.await`](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/workflow/Workflow.html#await(java.time.Duration,java.util.function.Supplier)), and more. See [Blocking handlers](#blocking-handlers) and [Workflow message passing](/encyclopedia/workflow-message-passing) for guidelines on safely using blocking Signal and Update handlers. -### Update handlers and validators {#updates} +### Update handlers and validators {/* #updates */} An [Update](/sending-messages#sending-updates) is a trackable synchronous request sent to a running Workflow Execution. It can change the Workflow state, control its flow, and return a result. @@ -214,7 +214,7 @@ public class MessagePassingIntro { - Signal (and Update) handlers can be blocking, letting them use Activities, Child Workflows, durable [`Workflow.sleep`](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/workflow/Workflow.html#sleep(java.time.Duration)) Timers, [`Workflow.await`](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/workflow/Workflow.html#await(java.time.Duration,java.util.function.Supplier)) conditions, and more. See [Blocking handlers](#blocking-handlers) and [Workflow message passing](/encyclopedia/workflow-message-passing) for safe usage guidelines. -## Send messages {#send-messages} +## Send messages {/* #send-messages */} To send Queries, Signals, or Updates you call methods on a `WorkflowInterface`, often called the "WorkflowStub." @@ -247,7 +247,7 @@ To check the argument types required when sending messages -- and the return typ ::: -### Send a Query {#send-query} +### Send a Query {/* #send-query */} Call a Query method defined within a Workflow from a `WorkflowStub` created in Client code to send a Query to a Workflow Execution: @@ -264,12 +264,12 @@ System.out.println("Supported languages: " + languages); - A Worker must be online and polling the Task Queue to process a Query. -### Send a Signal {#send-signal} +### Send a Signal {/* #send-signal */} You can send a Signal to a Workflow Execution from a Temporal Client or from another Workflow Execution. However, you can only send Signals to Workflow Executions that haven’t closed. -#### Send a Signal from a Client {#send-signal-from-client} +#### Send a Signal from a Client {/* #send-signal-from-client */} To send a Signal from Client code, call a Signal method on the WorkflowStub: @@ -281,7 +281,7 @@ workflow.approve(new ApproveInput("Me")); - The [WorkflowExecutionSignaled](/references/events#workflowexecutionsignaled) Event appears in the Workflow's Event History. -#### Send a Signal from a Workflow {#send-signal-from-workflow} +#### Send a Signal from a Workflow {/* #send-signal-from-workflow */} A Workflow can send a Signal to another Workflow, known as an _External Signal_. Use [`Workflow.newExternalWorkflowStub`](https://javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/workflow/Workflow.html#newExternalWorkflowStub(java.lang.Class,io.temporal.api.common.v1.WorkflowExecution)) in your _current_ Workflow to create an `ExternalWorkflowStub` for the other Workflow. @@ -297,7 +297,7 @@ When an External Signal is sent: - A [SignalExternalWorkflowExecutionInitiated](/references/events#signalexternalworkflowexecutioninitiated) Event appears in the sender's Event History. - A [WorkflowExecutionSignaled](/references/events#workflowexecutionsignaled) Event appears in the recipient's Event History. -#### Signal-With-Start {#signal-with-start} +#### Signal-With-Start {/* #signal-with-start */} Signal-With-Start allows a Client to send a Signal to a Workflow Execution, starting the Execution if it is not already running. If there's a Workflow running with the given Workflow Id, it will be signaled. @@ -336,7 +336,7 @@ public interface GreetingWorkflow { } ``` -### Send an Update {#send-update-from-client} +### Send an Update {/* #send-update-from-client */} An Update is a synchronous, blocking call that can change Workflow state, control its flow, and return a result. @@ -386,7 +386,7 @@ You can use the `WorkflowUpdateHandle` to obtain information about the update: - `getId()`: Returns the Update's unique ID, which can be useful for deduplication when using Continue-As-New: see [Ensuring your messages are processed exactly once](/handling-messages#exactly-once-message-processing). - `getResultAsync()`: Returns a `CompletableFuture` which can be used to wait for the Update to complete. -#### Update-With-Start {#update-with-start} +#### Update-With-Start {/* #update-with-start */} :::tip @@ -472,7 +472,7 @@ Pass method names instead of method objects to: ::: -## Message handler patterns {#message-handler-patterns} +## Message handler patterns {/* #message-handler-patterns */} This section covers common write operations, such as Signal and Update handlers. It doesn't apply to pure read operations, like Queries or Update Validators. @@ -483,7 +483,7 @@ For additional information, see [Inject work into the main Workflow](/handling-m ::: -### Do blocking operations in handlers {#blocking-handlers} +### Do blocking operations in handlers {/* #blocking-handlers */} Signal and Update handlers can block. This allows you to use [`Workflow.await`](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/workflow/Workflow.html#await(java.time.Duration,java.util.function.Supplier)), Activities, Child Workflows, [`Workflow.sleep`](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/workflow/Workflow.html#sleep(java.time.Duration)) Timers, etc. @@ -521,7 +521,7 @@ public static class GreetingWorkflowImpl implements GreetingWorkflow { Although a Signal handler can also make blocking calls like this, using an Update handler allows the Client to receive a result or error once the Activity completes. This lets your Client track the progress of asynchronous work performed by the Update's Activities, Child Workflows, etc. -### Add blocking wait conditions {#block-with-wait} +### Add blocking wait conditions {/* #block-with-wait */} Sometimes, blocking Signal or Update handlers need to meet certain conditions before they should continue. You can use [`Workflow.await`](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/workflow/Workflow.html#await(java.time.Duration,java.util.function.Supplier)) to prevent the code from proceeding until a condition is true. @@ -533,7 +533,7 @@ Here are two important use cases for `Workflow.await`: - Waiting in a handler until it is appropriate to continue. - Waiting in the main Workflow until all active handlers have finished. -#### Wait for conditions in handlers {#wait-in-handlers} +#### Wait for conditions in handlers {/* #wait-in-handlers */} It's common to use `Workflow.await` in a handler. For example, suppose your Workflow class has a `updateReadyToExecute` method that indicates whether your Update handler should be allowed to start executing. @@ -552,7 +552,7 @@ Remember: handlers can execute before the main Workflow method starts. You can also use `Workflow.await` anywhere else in the handler to wait for a specific condition to become true. This allows you to write handlers that pause at multiple points, each time waiting for a required condition to become true. -#### Ensure your handlers finish before the Workflow completes {#wait-for-message-handlers} +#### Ensure your handlers finish before the Workflow completes {/* #wait-for-message-handlers */} `Workflow.await` can ensure your handler completes before a Workflow finishes. When your Workflow uses blocking Signal or Update handlers, your main Workflow method can return or Continue-as-New while a handler is still waiting on an async task, such as an Activity. @@ -642,7 +642,7 @@ public class GreetingExample { } ``` -### Use locks to prevent concurrent handler execution {#control-handler-concurrency} +### Use locks to prevent concurrent handler execution {/* #control-handler-concurrency */} Concurrent processes can interact in unpredictable ways. Incorrectly written [concurrent message-passing](/handling-messages#message-handler-concurrency) code may not work correctly when multiple handler instances run simultaneously. @@ -688,7 +688,7 @@ public class DataWorkflowImpl implements DataWorkflow { } ``` -## Message handler troubleshooting {#message-handler-troubleshooting} +## Message handler troubleshooting {/* #message-handler-troubleshooting */} When sending a Signal, Update, or Query to a Workflow, your Client might encounter the following errors: @@ -700,14 +700,14 @@ When sending a Signal, Update, or Query to a Workflow, your Client might encount See [Exceptions in message handlers](/handling-messages#exceptions) for a non–Java-specific discussion of this topic. -### Problems when sending a Signal {#signal-problems} +### Problems when sending a Signal {/* #signal-problems */} When using Signal, the above `WorkflowException`s are the only types of exception that will result from the request. In contrast, for Queries and Updates, the client waits for a response from the Worker. If an issue occurs during the handler execution by the Worker, the Client may receive an exception. -### Problems when sending an Update {#update-problems} +### Problems when sending an Update {/* #update-problems */} When working with Updates, you may encounter these errors: @@ -747,7 +747,7 @@ When working with Updates, you may encounter these errors: - The Workflow completed normally or continued-as-new and the Workflow author did not [wait for handlers to be finished](/handling-messages#finishing-message-handlers). -### Problems when sending a Query {#query-problems} +### Problems when sending a Query {/* #query-problems */} When working with Queries, you may encounter these errors: @@ -762,7 +762,7 @@ When working with Queries, you may encounter these errors: - **The handler caused the Workflow Task to fail.** This would happen, for example, if the Query handler blocks the thread for too long without yielding. -## Dynamic components {#dynamic-handler} +## Dynamic components {/* #dynamic-handler */} A dynamic Workflow, Activity, Signal, Update, or Query is a kind of unnamed item. Normally, these items are registered by name with the Worker and invoked at runtime. @@ -783,7 +783,7 @@ Reserve dynamic invocation use for cases where a name is not or can't be known a ::: -### Set a Dynamic Workflow {#set-a-dynamic-workflow} +### Set a Dynamic Workflow {/* #set-a-dynamic-workflow */} Use [`DynamicWorkflow`](https://www.javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/workflow/DynamicWorkflow.html) to implement Workflow Types dynamically. Register a Workflow implementation type that extends `DynamicWorkflow` to implement any Workflow Type that is not explicitly registered with the Worker. @@ -799,7 +799,7 @@ public class MyDynamicWorkflow implements DynamicWorkflow { } ``` -### How to set a Dynamic Activity {#set-a-dynamic-activity} +### How to set a Dynamic Activity {/* #set-a-dynamic-activity */} To handle Activity types that do not have an explicitly registered handler, you can directly implement a dynamic Activity. @@ -827,7 +827,7 @@ The dynamic Activity interface is implemented with the `execute` method, as show Use `Activity.getExecutionContext()` to get information about the Activity type that should be implemented dynamically. -### How to set a Dynamic Signal {#set-a-dynamic-signal} +### How to set a Dynamic Signal {/* #set-a-dynamic-signal */} You can also implement Signal handlers dynamically. This is useful for library-level code and implementation of DSLs. @@ -843,7 +843,7 @@ When registered, any Signals sent to the Workflow without a defined handler will Note that you can only register one `Workflow.registerListener(Object)` per Workflow Execution. `DynamicSignalHandler` can be implemented in both regular and dynamic Workflow implementations. -### How to set a Dynamic Query {#set-a-dynamic-query} +### How to set a Dynamic Query {/* #set-a-dynamic-query */} You can also implement Query handlers dynamically. This is useful for library-level code and implementation of DSLs. @@ -859,7 +859,7 @@ When registered, any Queries sent to the Workflow without a defined handler will Note that you can only register one `Workflow.registerListener(Object)` per Workflow Execution. `DynamicQueryHandler` can be implemented in both regular and dynamic Workflow implementations. -### How to set a Dynamic Update {#set-a-dynamic-update} +### How to set a Dynamic Update {/* #set-a-dynamic-update */} You can also implement Update handlers dynamically. This is useful for library-level code and implementation of DSLs. diff --git a/docs/develop/java/workflows/schedules.mdx b/docs/develop/java/workflows/schedules.mdx index 7a239187b1..e0cf6bd28c 100644 --- a/docs/develop/java/workflows/schedules.mdx +++ b/docs/develop/java/workflows/schedules.mdx @@ -28,13 +28,13 @@ This page shows how to do the following: - [How to set a Cron Schedule in Java](#cron-schedule) - [Start Delay](#start-delay) -## How to Schedule a Workflow {#schedule-a-workflow} +## How to Schedule a Workflow {/* #schedule-a-workflow */} 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 actions to help Schedule a Workflow Execution and take control over your automation process. -### How to create a Schedule in Java {#create-schedule} +### How to create a Schedule in Java {/* #create-schedule */} The create action enables you to create a new Schedule. When you create a new Schedule, a unique Schedule ID is generated, which you can use to reference the Schedule in other Schedule commands. @@ -78,7 +78,7 @@ The Temporal Service doesn't guarantee when this removal will happen. ::: -### How to backfill a Schedule in Java {#backfill-schedule} +### How to backfill a Schedule in Java {/* #backfill-schedule */} The backfill action executes Actions ahead of their specified time range. This command is useful when you need to execute a missed or delayed Action, or when you want to test the Workflow before its scheduled time. @@ -94,7 +94,7 @@ handle.backfill( new ScheduleBackfill(now.minusMillis(2500), now))); ``` -### How to delete a Schedule in Java {#delete-schedule} +### How to delete a Schedule in Java {/* #delete-schedule */} The delete action enables you to delete a Schedule. When you delete a Schedule, it does not affect any Workflows that were started by the Schedule. @@ -105,7 +105,7 @@ ScheduleHandle handle = client.getHandle("schedule-id") handle.delete(); ``` -### How to describe a Schedule in Java {#describe-schedule} +### How to describe a Schedule in Java {/* #describe-schedule */} The describe action shows the current Schedule configuration, including information about past, current, and future Workflow Runs. This command is helpful when you want to get a detailed view of the Schedule and its associated Workflow Runs. @@ -116,7 +116,7 @@ ScheduleHandle handle = client.getHandle("schedule-id") ScheduleDescription description = handle.describe(); ``` -### How to list a Schedule in Java {#list-schedule} +### How to list a Schedule in Java {/* #list-schedule */} The list action lists all the available Schedules. This command is useful when you want to view a list of all the Schedules and their respective Schedule IDs. @@ -127,7 +127,7 @@ If a schedule is added or deleted, it may not be available in the list immediate Stream scheduleStream = client.listSchedules(); ``` -### How to pause a Schedule in Java {#pause-schedule} +### How to pause a Schedule in Java {/* #pause-schedule */} The pause action enables you to pause and unpause a Schedule. When you pause a Schedule, all the future Workflow Runs associated with the Schedule are temporarily stopped. This command is useful when you want to temporarily halt a Workflow due to maintenance or any other reason. @@ -139,7 +139,7 @@ ScheduleHandle handle = client.getHandle("schedule-id") handle.pause("Pausing the schedule for now"); ``` -### How to trigger a Schedule in Java {#trigger-schedule} +### How to trigger a Schedule in Java {/* #trigger-schedule */} The trigger action triggers an immediate action with a given Schedule. By default, this action is subject to the Overlap Policy of the Schedule. This command is helpful when you want to execute a Workflow outside of its scheduled time. @@ -150,7 +150,7 @@ ScheduleHandle handle = client.getHandle("schedule-id") handle.trigger(); ``` -### How to update a Schedule in Java {#update-schedule} +### How to update a Schedule in Java {/* #update-schedule */} The update action enables you to update an existing Schedule. This command is useful when you need to modify the Schedule's configuration, such as changing the start time, end time, or interval. @@ -173,7 +173,7 @@ handle.update( }); ``` -## How to set a Cron Schedule in Java {#cron-schedule} +## How to set a Cron Schedule in Java {/* #cron-schedule */} :::caution Cron support is not recommended @@ -221,7 +221,7 @@ Temporal Workflow Schedule Cron strings follow this format: For more details, see the [Cron Sample](https://github.com/temporalio/samples-java/blob/main/core/src/main/java/io/temporal/samples/hello/HelloCron.java) -## Start Delay {#start-delay} +## Start Delay {/* #start-delay */} **How to delay the start of a Workflow Execution using Start Delay with the Temporal Java SDK.** diff --git a/docs/develop/java/workflows/side-effects.mdx b/docs/develop/java/workflows/side-effects.mdx index cb8e8dac20..f18a9a3261 100644 --- a/docs/develop/java/workflows/side-effects.mdx +++ b/docs/develop/java/workflows/side-effects.mdx @@ -13,7 +13,7 @@ tags: description: Side Effects in a Workflow execute non-deterministic code like generating a UUID. The result is saved in Workflow Event History for consistent replays without re-execution. --- -## Side Effects {#side-effects} +## Side Effects {/* #side-effects */} Side Effects are used to execute non-deterministic code, such as generating a UUID or a random number, without compromising determinism in the Workflow. This is done by storing the non-deterministic results of the Side Effect into the Workflow [Event History](/workflow-execution/event#event-history). diff --git a/docs/develop/java/workflows/timeouts.mdx b/docs/develop/java/workflows/timeouts.mdx index 78b64dc69b..23255c0df5 100644 --- a/docs/develop/java/workflows/timeouts.mdx +++ b/docs/develop/java/workflows/timeouts.mdx @@ -17,7 +17,7 @@ tags: - Temporal SDKs --- -## Workflow timeouts {#workflow-timeouts} +## Workflow timeouts {/* #workflow-timeouts */} Each Workflow timeout controls the maximum duration of a different aspect of a Workflow Execution. @@ -54,7 +54,7 @@ YourWorkflowInterface workflow1 = .build()); ``` -## Workflow Retry Policy {#workflow-retries} +## Workflow Retry Policy {/* #workflow-retries */} **How to set a Workflow Retry Policy in Java.** diff --git a/docs/develop/java/workflows/timers.mdx b/docs/develop/java/workflows/timers.mdx index 39e0b82eda..b92610670f 100644 --- a/docs/develop/java/workflows/timers.mdx +++ b/docs/develop/java/workflows/timers.mdx @@ -14,7 +14,7 @@ tags: description: A Workflow sets a durable Timer for delayed execution. Even if the Worker or Temporal Service is down, the Timer resumes once back up. Efficient and scalable. --- -## What is a Timer? {#timers} +## What is a Timer? {/* #timers */} A Workflow can set a durable Timer for a fixed time period. In some SDKs, the function is called `sleep()`, and in others, it's called `timer()`. diff --git a/docs/develop/java/workflows/versioning.mdx b/docs/develop/java/workflows/versioning.mdx index f20b717363..a57d5d33ce 100644 --- a/docs/develop/java/workflows/versioning.mdx +++ b/docs/develop/java/workflows/versioning.mdx @@ -37,7 +37,7 @@ Support for the experimental Worker Versioning method before 2025 will be remove Temporal's [Worker Versioning](/production-deployment/worker-deployments/worker-versioning) feature allows you to tag your Workers and programmatically roll them out in Deployment Versions, so that old Workers can run old code paths and new Workers can run new code paths. This way, you can pin your Workflows to specific revisions, avoiding the need for patching. -## Versioning with Patching {#patching} +## Versioning with Patching {/* #patching */} ### Patching with GetVersion diff --git a/docs/develop/php/activities/asynchronous-activity.mdx b/docs/develop/php/activities/asynchronous-activity.mdx index 5da8e7d76d..d6197437aa 100644 --- a/docs/develop/php/activities/asynchronous-activity.mdx +++ b/docs/develop/php/activities/asynchronous-activity.mdx @@ -15,7 +15,7 @@ description: facilitating parallel operations in Workflows. --- -## How to asynchronously complete an Activity {#asynchronous-activity-completion} +## How to asynchronously complete an Activity {/* #asynchronous-activity-completion */} [Asynchronous Activity Completion](/activity-execution#asynchronous-activity-completion) enables the Activity Function to return without the Activity Execution completing. diff --git a/docs/develop/php/activities/basics.mdx b/docs/develop/php/activities/basics.mdx index 5d9f306ef9..c14f3c3a80 100644 --- a/docs/develop/php/activities/basics.mdx +++ b/docs/develop/php/activities/basics.mdx @@ -11,7 +11,7 @@ tags: - Temporal SDKs --- -## How to develop a basic Activity {#develop-activities} +## How to develop a basic Activity {/* #develop-activities */} One of the primary things that Workflows do is orchestrate the execution of Activities. An Activity is a normal function or method execution that's intended to execute a single, well-defined action (either short or long-running), such as querying a database, calling a third-party API, or transcoding a media file. @@ -38,7 +38,7 @@ interface FileProcessingActivities } ``` -### How to develop Activity Parameters {#activity-parameters} +### How to develop Activity Parameters {/* #activity-parameters */} There is no explicit limit to the total number of parameters that an [Activity Definition](/activity-definition) may support. However, there is a limit to the total size of the data that ends up encoded into a gRPC message Payload. @@ -61,7 +61,7 @@ A single Workflow can use more than one Activity interface and call more than on The only requirement is that Activity method arguments and return values are serializable to a byte array using the provided [DataConverter](https://github.com/temporalio/sdk-php/blob/master/src/DataConverter/DataConverterInterface.php) interface. The default implementation uses a JSON serializer, but an alternative implementation can be easily configured. -### How to define Activity return values {#activity-return-values} +### How to define Activity return values {/* #activity-return-values */} All data returned from an Activity must be serializable. @@ -93,7 +93,7 @@ class GreetingActivity implements GreetingActivityInterface } ``` -### How to customize your Activity Type {#activity-type} +### How to customize your Activity Type {/* #activity-type */} Activities have a Type that are referred to as the Activity name. The following examples demonstrate how to set a custom name for your Activity Type. diff --git a/docs/develop/php/activities/execution.mdx b/docs/develop/php/activities/execution.mdx index 6fca109480..f61960772b 100644 --- a/docs/develop/php/activities/execution.mdx +++ b/docs/develop/php/activities/execution.mdx @@ -11,7 +11,7 @@ tags: - Activity --- -## How to start an Activity Execution {#activity-execution} +## How to start an Activity Execution {/* #activity-execution */} 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. @@ -83,13 +83,13 @@ class FileProcessingActivitiesImpl implements FileProcessingActivities { } ``` -### How to set the required Activity Timeouts {#required-timeout} +### How to set the required Activity Timeouts {/* #required-timeout */} Activity Execution semantics rely on several parameters. The only required value that needs to be set is either a [Schedule-To-Close Timeout](/encyclopedia/detecting-activity-failures#schedule-to-close-timeout) or a [Start-To-Close Timeout](/encyclopedia/detecting-activity-failures#start-to-close-timeout). These values are set in the Activity Options. -### How to get the results of an Activity Execution {#get-activity-results} +### How to get the results of an Activity Execution {/* #get-activity-results */} The call to spawn an [Activity Execution](/activity-execution) generates the [ScheduleActivityTask](/references/commands#scheduleactivitytask) Command and provides the Workflow with an Awaitable. Workflow Executions can either block progress until the result is available through the Awaitable or continue progressing, making use of the result when it becomes available. diff --git a/docs/develop/php/activities/timeouts.mdx b/docs/develop/php/activities/timeouts.mdx index 6a18a3071f..6d6a32c847 100644 --- a/docs/develop/php/activities/timeouts.mdx +++ b/docs/develop/php/activities/timeouts.mdx @@ -17,7 +17,7 @@ tags: - Temporal SDKs --- -## How to set Activity timeouts {#activity-timeouts} +## How to set Activity timeouts {/* #activity-timeouts */} Each Activity timeout controls the maximum duration of a different aspect of an Activity Execution. @@ -48,7 +48,7 @@ $this->greetingActivity = Workflow::newActivityStub( ); ``` -### How to set an Activity Retry Policy {#activity-retries} +### How to set an Activity Retry Policy {/* #activity-retries */} A Retry Policy works in cooperation with the timeouts to provide fine controls to optimize the execution experience. @@ -74,13 +74,13 @@ $this->greetingActivity = Workflow::newActivityStub( For an executable code sample, see [ActivityRetry sample](https://github.com/temporalio/samples-php/tree/master/app/src/ActivityRetry) in the PHP samples repository. -### How to set the required Activity Timeouts {#required-timeout} +### How to set the required Activity Timeouts {/* #required-timeout */} Activity Execution semantics rely on several parameters. The only required value that needs to be set is either a [Schedule-To-Close Timeout](/encyclopedia/detecting-activity-failures#start-to-close-timeout) or a [Start-To-Close Timeout](/encyclopedia/detecting-activity-failures#start-to-close-timeout). These values are set in the Activity Options. -## Activity next Retry delay {#activity-next-retry-delay} +## Activity next Retry delay {/* #activity-next-retry-delay */} **How to override the next Retry delay following an Activity failure using the Temporal PHP SDK** @@ -100,7 +100,7 @@ throw new \Temporal\Exception\Failure\ApplicationFailure( ); ``` -## How to Heartbeat an Activity {#activity-heartbeats} +## How to Heartbeat an Activity {/* #activity-heartbeats */} An [Activity Heartbeat](/encyclopedia/detecting-activity-failures#activity-heartbeat) is a ping from the [Worker Process](/workers#worker-process) that is executing the Activity to the [Temporal Service](/temporal-service). Each Heartbeat informs the Temporal Service that the [Activity Execution](/activity-execution) is making progress and the Worker has not crashed. @@ -155,7 +155,7 @@ class FileProcessingActivitiesImpl implements FileProcessingActivities } ``` -#### How to set a Heartbeat Timeout {#heartbeat-timeout} +#### How to set a Heartbeat Timeout {/* #heartbeat-timeout */} A [Heartbeat Timeout](/encyclopedia/detecting-activity-failures#heartbeat-timeout) works in conjunction with [Activity Heartbeats](/encyclopedia/detecting-activity-failures#activity-heartbeat). diff --git a/docs/develop/php/best-practices/debugging.mdx b/docs/develop/php/best-practices/debugging.mdx index 3b5a54b673..c9535f88cc 100644 --- a/docs/develop/php/best-practices/debugging.mdx +++ b/docs/develop/php/best-practices/debugging.mdx @@ -13,13 +13,13 @@ tags: - Temporal SDKs --- -## Debugging {#debug} +## Debugging {/* #debug */} -### How to debug in a development environment {#debug-in-a-development-environment} +### How to debug in a development environment {/* #debug-in-a-development-environment */} 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 production environment {#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/best-practices/testing-suite.mdx b/docs/develop/php/best-practices/testing-suite.mdx index c82642ddfe..db1e1cddd4 100644 --- a/docs/develop/php/best-practices/testing-suite.mdx +++ b/docs/develop/php/best-practices/testing-suite.mdx @@ -28,14 +28,14 @@ We generally recommend writing the majority of your tests as integration tests. Because the test server supports skipping time, use the test server for both end-to-end and integration tests with Workers. -## Testing Activities {#test-activities} +## Testing Activities {/* #test-activities */} An Activity can be tested with a mock Activity environment, which provides a way to mock the Activity context, listen to Heartbeats, and cancel the Activity. This behavior allows you to test the Activity in isolation by calling it directly, without needing to create a Worker to run the Activity. -## Testing Workflows {#test-workflows} +## Testing Workflows {/* #test-workflows */} -### How to mock Activities {#mock-activities} +### How to mock Activities {/* #mock-activities */} Mock the Activity invocation when unit testing your Workflows. @@ -125,7 +125,7 @@ To mock a failure, use the `expectFailure()` method: $this->activityMocks->expectFailure('SimpleActivity.echo', new \LogicException('something went wrong')); ``` -### How to skip time {#skip-time} +### How to skip time {/* #skip-time */} Some long-running Workflows can persist for months or even years. Implementing the test framework allows your Workflow code to skip time and complete your tests in seconds rather than the Workflow's specified amount. @@ -138,7 +138,7 @@ Time is a global property of an instance of `TestWorkflowEnvironment`: skipping If you need different time behaviors for different tests, run your tests in a series or with separate instances of the test server. For example, you could run all tests with automatic time skipping in parallel, and then all tests with manual time skipping in series, and then all tests without time skipping in parallel. -#### Set up time skipping {#setting-up} +#### Set up time skipping {/* #setting-up */} Set up the time-skipping test framework in the SDK of your choice. @@ -185,7 +185,7 @@ if (getenv('RUN_TEMPORAL_TEST_SERVER') !== false) { temporal-test-server ``` -## How to Replay a Workflow Execution {#replay} +## How to Replay a Workflow Execution {/* #replay */} Replay recreates the exact state of a Workflow Execution. You can replay a Workflow from the beginning of its Event History. diff --git a/docs/develop/php/client/temporal-client.mdx b/docs/develop/php/client/temporal-client.mdx index 35eee92447..0bd9f3bec4 100644 --- a/docs/develop/php/client/temporal-client.mdx +++ b/docs/develop/php/client/temporal-client.mdx @@ -24,7 +24,7 @@ This page shows how to do the following: - [Start a Workflow Execution](#start-workflow-execution) - [Advanced connection options](#advanced-connection-options) -## How to connect a Temporal Client to a Temporal Service {#connect-to-a-dev-cluster} +## How to connect a Temporal Client to a Temporal Service {/* #connect-to-a-dev-cluster */} A [Temporal Client](/encyclopedia/temporal-sdks#temporal-client) enables you to communicate with the [Temporal Service](/temporal-service). Communication with a Temporal Service includes, but isn't limited to, the following: @@ -71,7 +71,7 @@ $workflowClient = WorkflowClient::create($serviceClient); See the [Advanced connection options](#advanced-connection-options) section for more information on configuring the connection. -## How to connect a Temporal Client to a Temporal Cloud {#connect-to-temporal-cloud} +## How to connect a Temporal Client to a Temporal Cloud {/* #connect-to-temporal-cloud */} When you connect to [Temporal Cloud](/cloud), you need to provide additional connection and client options that include the following: @@ -129,7 +129,7 @@ $serviceClient = \Temporal\Client\GRPC\ServiceClient::createSSL(/*...*/) ->withAuthKey('your-api-key'); ``` -## How to start a Workflow Execution {#start-workflow-execution} +## How to start a Workflow Execution {/* #start-workflow-execution */} [Workflow Execution](/workflow-execution) semantics rely on several parameters—that is, to start a Workflow Execution you must supply a Task Queue that will be used for the Tasks (one that a Worker is polling), the Workflow Type, language-specific contextual data, and Workflow Function parameters. @@ -255,7 +255,7 @@ var_dump($run->getResult(timeout: 10)); You can start a Workflow Execution on a regular schedule with [the CronSchedule option](/develop/php/workflows/schedules#temporal-cron-jobs). -### How to set a Workflow's Task Queue {#set-task-queue} +### How to set a Workflow's Task Queue {/* #set-task-queue */} In most SDKs, the only Workflow Option that must be set is the name of the [Task Queue](/task-queue). When developing in PHP, the Task Queue name defaults to `"default"`. @@ -280,7 +280,7 @@ $stub = $workflowClient->newWorkflowStub( ); ``` -### How to set a Workflow Id {#workflow-id} +### How to set a Workflow Id {/* #workflow-id */} Although it is not required, we recommend providing your own [Workflow Id](/workflow-execution/workflowid-runid#workflow-id)that maps to a business process or business entity identifier, such as an order identifier or customer identifier. @@ -294,7 +294,7 @@ $stub = $workflowClient->newWorkflowStub( ); ``` -### How to get the results of a Workflow Execution {#get-workflow-results} +### How to get the results of a Workflow Execution {/* #get-workflow-results */} If the call to start a Workflow Execution is successful, you will gain access to the Workflow Execution's Run Id. @@ -327,7 +327,7 @@ Note that you can specify a timeout for the `getResult()` method in seconds. If the Workflow does not complete within the specified time, a `TimeoutException` will be thrown. See how to limit all RPC calls in the [RPC timeout](#configure-rpc-timeout) section. -## Advanced connection options {#advanced-connection-options} +## Advanced connection options {/* #advanced-connection-options */} In PHP, it is common practice to work with resources in blocking mode. Long blocks can quickly exhaust the pool of available workers and lead to application failure. @@ -349,7 +349,7 @@ $serviceClient->getServerCapabilities(); If, for some reason, the established connection is broken, the SDK will automatically attempt to restore it, taking into account the configured retry policy. -### Retry policy {#configure-rpc-retry-policy} +### Retry policy {/* #configure-rpc-retry-policy */} Whenever the client fails to connect to the server, an error with a status code is generated. If the status code is `UNKNOWN`, `UNAVAILABLE`, or `RESOURCE_EXHAUSTED`, the client will make another connection attempt. @@ -375,7 +375,7 @@ $workflowClient = WorkflowClient::create($serviceClient) ); ``` -### RPC timeout {#configure-rpc-timeout} +### RPC timeout {/* #configure-rpc-timeout */} When the client calls the service's RPC, there is no default time limit for waiting for a response. This can result in the code call `$result = $workflowHandle->getResult();` blocking the PHP worker until the Workflow completes. In some cases, this is not the desired behavior, and there may be a need to set a reasonable timeout for waiting for the RPC to complete. diff --git a/docs/develop/php/platform/observability.mdx b/docs/develop/php/platform/observability.mdx index c72026f483..f9bd951077 100644 --- a/docs/develop/php/platform/observability.mdx +++ b/docs/develop/php/platform/observability.mdx @@ -27,7 +27,7 @@ This section covers features related to viewing the state of the application, in - [Log from a Workflow](#logging) - [Visibility](#visibility) -## Log from a Workflow {#logging} +## Log from a Workflow {/* #logging */} Logging enables you to record critical information during code execution. Loggers create an audit trail and capture information about your Workflow's operation. @@ -85,7 +85,7 @@ By default, PHP SDK uses a [`StderrLogger`](https://php.temporal.io/classes/Temp These messages are automatically captured by RoadRunner and incorporated into its logging system with the INFO level, ensuring proper log collection in both development and production environments. For more details on RoadRunner's logging capabilities, see the [RoadRunner Logger documentation](https://docs.roadrunner.dev/docs/logging-and-observability/logger). -### How to provide a custom logger {#custom-logger} +### How to provide a custom logger {/* #custom-logger */} You can set a custom PSR-3 compatible logger when creating a Worker: @@ -99,11 +99,11 @@ $worker = $workerFactory->newWorker( ); ``` -## Visibility APIs {#visibility} +## Visibility APIs {/* #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 Temporal Service. -### How to use Search Attributes {#search-attributes} +### How to use Search Attributes {/* #search-attributes */} The typical method of retrieving a Workflow Execution is by its Workflow Id. @@ -140,7 +140,7 @@ foreach ($paginator as $info) { } ``` -### How to set custom Search Attributes {#custom-search-attributes} +### How to set custom Search Attributes {/* #custom-search-attributes */} After you've created custom Search Attributes in your Temporal Service (using `temporal operator search-attribute create` or the Cloud UI), you can set the values of the custom Search Attributes when starting a Workflow. @@ -163,7 +163,7 @@ $workflow = $workflowClient->newWorkflowStub( ); ``` -### How to upsert Search Attributes {#upsert-search-attributes} +### How to upsert Search Attributes {/* #upsert-search-attributes */} Within the Workflow code, you can dynamically add or update Search Attributes using [`upsertTypedSearchAttributes`](https://php.temporal.io/classes/Temporal-Workflow.html#method_upsertTypedSearchAttributes). This method is particularly useful for Workflows whose attributes need to change based on internal logic or external events. @@ -184,7 +184,7 @@ public function postponeDestinationTime(\DateInterval $interval) } ``` -### How to remove a Search Attribute from a Workflow {#remove-search-attribute} +### How to remove a Search Attribute from a Workflow {/* #remove-search-attribute */} To remove a Search Attribute that was previously set, set it to an empty Map. diff --git a/docs/develop/php/workers/run-worker-process.mdx b/docs/develop/php/workers/run-worker-process.mdx index 98f3461a9c..ff87a0fe8c 100644 --- a/docs/develop/php/workers/run-worker-process.mdx +++ b/docs/develop/php/workers/run-worker-process.mdx @@ -11,7 +11,7 @@ tags: - Worker --- -## How to run Worker Processes {#run-a-dev-worker} +## How to run Worker Processes {/* #run-a-dev-worker */} The [Worker Process](/workers#worker-process) is where Workflow Functions and Activity Functions are executed. @@ -114,7 +114,7 @@ $workerFactory = \Temporal\WorkerFactory::create( [How to configure connection to a Temporal Cloud](/develop/php/client/temporal-client#connect-to-temporal-cloud) -### How to register types {#register-types} +### How to register types {/* #register-types */} All Workers listening to the same Task Queue name must be registered to handle the exact same Workflows Types and Activity Types. diff --git a/docs/develop/php/workflows/basics.mdx b/docs/develop/php/workflows/basics.mdx index f11c171b2d..26c0ad23cd 100644 --- a/docs/develop/php/workflows/basics.mdx +++ b/docs/develop/php/workflows/basics.mdx @@ -11,7 +11,7 @@ tags: - Temporal SDKs --- -## How to develop a basic Workflow {#develop-workflows} +## How to 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 @@ interface FileProcessingWorkflow } ``` -### How to define Workflow parameters {#workflow-parameters} +### How to 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. @@ -52,7 +52,7 @@ interface FileProcessingWorkflow { } ``` -### How to define Workflow return parameters {#workflow-return-values} +### How to define Workflow return parameters {/* #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. @@ -71,7 +71,7 @@ interface FileProcessingWorkflow { } ``` -### How to customize your Workflow Type {#workflow-type} +### How to customize your Workflow Type {/* #workflow-type */} Workflows have a Type that are referred to as the Workflow name. @@ -94,7 +94,7 @@ interface YourWorkflowDefinitionInterface } ``` -### How to develop Workflow logic {#workflow-logic-requirements} +### How to develop Workflow logic {/* #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/php/workflows/cancellation.mdx b/docs/develop/php/workflows/cancellation.mdx index 7f2bbcba03..15cdcaaa86 100644 --- a/docs/develop/php/workflows/cancellation.mdx +++ b/docs/develop/php/workflows/cancellation.mdx @@ -17,7 +17,7 @@ description: for handling Activity cancellations to ensure proper Workflow management. --- -## Cancel an Activity from a Workflow {#cancel-an-activity} +## Cancel an Activity from a Workflow {/* #cancel-an-activity */} Canceling an Activity from within a Workflow requires that the Activity Execution sends Heartbeats and sets a Heartbeat Timeout. If the Heartbeat is not invoked, the Activity cannot receive a cancellation request. When any non-immediate @@ -37,7 +37,7 @@ Worker process. ::: -## Reset a Workflow Execution {#reset} +## Reset a Workflow Execution {/* #reset */} Resetting a Workflow Execution terminates the current Workflow Execution and starts a new Workflow Execution from a point you specify in its Event History. Use reset when a Workflow is blocked due to a non-deterministic error or other diff --git a/docs/develop/php/workflows/child-workflows.mdx b/docs/develop/php/workflows/child-workflows.mdx index 62a0842fc7..8548e3529c 100644 --- a/docs/develop/php/workflows/child-workflows.mdx +++ b/docs/develop/php/workflows/child-workflows.mdx @@ -14,7 +14,7 @@ tags: description: Start a Child Workflow Execution within a parent Workflow using Temporal in PHP. Configure ChildWorkflowOptions, handle Parent Close Policy, and implement asynchronous calls with promises. --- -## How to start a Child Workflow Execution {#child-workflows} +## How to start a Child Workflow Execution {/* #child-workflows */} A [Child Workflow Execution](/child-workflows) is a Workflow Execution that is scheduled from within another Workflow using a Child Workflow API. @@ -78,7 +78,7 @@ $childResult = yield Workflow::executeChildWorkflow( ); ``` -#### How to set a Parent Close Policy {#parent-close-policy} +#### How to set a Parent Close Policy {/* #parent-close-policy */} A [Parent Close Policy](/parent-close-policy) determines what happens to a Child Workflow Execution if its Parent changes to a Closed status (Completed, Failed, or Timed Out). diff --git a/docs/develop/php/workflows/continue-as-new.mdx b/docs/develop/php/workflows/continue-as-new.mdx index 8e828f2740..b10bb7aa46 100644 --- a/docs/develop/php/workflows/continue-as-new.mdx +++ b/docs/develop/php/workflows/continue-as-new.mdx @@ -24,7 +24,7 @@ This page answers the following questions for PHP developers: - [When is it right to Continue-as-New?](#when) - [How to test Continue-as-New?](#how-to-test) -## What is Continue-As-New? {#what} +## What is Continue-As-New? {/* #what */} [Continue-As-New](/workflow-execution/continue-as-new) lets a Workflow Execution close successfully and creates a new Workflow Execution. You can think of it as a checkpoint when your Workflow gets too long or approaches certain scaling limits. @@ -32,7 +32,7 @@ You can think of it as a checkpoint when your Workflow gets too long or approach The new Workflow Execution is in the same [chain](/workflow-execution#workflow-execution-chain); it keeps the same Workflow Id but gets a new Run Id and a fresh Event History. It also receives your Workflow's usual parameters. -## How to Continue-As-New using the PHP SDK {#how} +## How to Continue-As-New using the PHP SDK {/* #how */} First, design your Workflow parameters so that you can pass in the "current state" when you Continue-As-New into the next Workflow run. This state is typically set to `None` for the original caller of the Workflow. @@ -77,20 +77,20 @@ Workflow::continueAsNew( ); ```` -### Considerations for Workflows with Message Handlers {#with-message-handlers} +### Considerations for Workflows with Message Handlers {/* #with-message-handlers */} If you use Updates or Signals, don't call Continue-as-New from the handlers. Instead, wait for your handlers to finish in your main Workflow before you run `continueAsNew`. See the [`allHandlersFinished`](message-passing#wait-for-message-handlers) example for guidance. -## When is it right to Continue-as-New using the PHP SDK? {#when} +## When is it right to Continue-as-New using the PHP SDK? {/* #when */} Use Continue-as-New when your Workflow might hit [Event History Limits](/workflow-execution/event#event-history). Temporal tracks your Workflow's progress against these limits to let you know when you should Continue-as-New. Call `Workflow::getInfo()->shouldContinueAsNew` to check if it's time. -## How to test Continue-as-New using the PHP SDK {#how-to-test} +## How to test Continue-as-New using the PHP SDK {/* #how-to-test */} Testing Workflows that naturally Continue-as-New may be time-consuming and resource-intensive. Instead, add a test hook to check your Workflow's Continue-as-New behavior faster in automated tests. diff --git a/docs/develop/php/workflows/message-passing.mdx b/docs/develop/php/workflows/message-passing.mdx index b88daa6e9d..1fa4b51de4 100644 --- a/docs/develop/php/workflows/message-passing.mdx +++ b/docs/develop/php/workflows/message-passing.mdx @@ -22,14 +22,14 @@ tags: description: Develop with Signals, Queries, and Updates in Temporal Workflows. Define, handle, and send Signals or Queries, and validate updates from a Temporal Client. --- -## How to develop with Signals {#signals} +## How to develop with Signals {/* #signals */} A [Signal](/sending-messages#sending-signals) is a message sent to a running Workflow Execution. Signals are defined in your code and handled in your Workflow Definition. Signals can be sent to Workflow Executions from a Temporal Client or from another Workflow Execution. -### How to define a Signal {#define-signal} +### How to define a Signal {/* #define-signal */} A Signal has a name and can have arguments. @@ -83,7 +83,7 @@ If name is not specified the short name of the Workflow interface is used. In the preceding code the `#[WorkflowMethod(name)]` is not specified, thus the Workflow Type defaults to `"FileProcessingWorkflow"`. -### How to handle a Signal {#handle-signal} +### How to handle a Signal {/* #handle-signal */} Workflows listen for Signals by the Signal's name. @@ -115,7 +115,7 @@ class YourWorkflow In the preceding example, the Workflow updates the protected value. The main Workflow coroutine waits for the value to change by using the `Workflow::await()` function. -### How to send a Signal from a Temporal Client {#send-signal-from-client} +### How to send a Signal from a Temporal Client {/* #send-signal-from-client */} When a Signal is sent successfully from the Temporal Client, the [WorkflowExecutionSignaled](/references/events#workflowexecutionsignaled) Event appears in the Event History of the Workflow that receives the Signal. @@ -144,7 +144,7 @@ $workflow->setValue(true); See [Handle Signal](#handle-signal) for details on how to handle Signals in a Workflow. -### How to send a Signal from a Workflow {#send-signal-from-workflow} +### How to send a Signal from a Workflow {/* #send-signal-from-workflow */} A Workflow can send a Signal to another Workflow, in which case it's called an _External Signal_. @@ -175,7 +175,7 @@ $workflow = $workflowClient->newRunningWorkflowStub(YourWorkflow::class, 'workfl $workflow->setValue(true); ``` -### How to Signal-With-Start {#signal-with-start} +### How to Signal-With-Start {/* #signal-with-start */} Signal-With-Start is used from the Client. It takes a Workflow Id, Workflow arguments, a Signal name, and Signal arguments. @@ -197,11 +197,11 @@ $run = $workflowClient->startWithSignal( ); ``` -## How to develop with Queries {#queries} +## How to develop with Queries {/* #queries */} A [Query](/sending-messages#sending-queries) is a synchronous operation that is used to get the state of a Workflow Execution. -### How to define a Query {#define-query} +### How to define a Query {/* #define-query */} A Query has a name and can have arguments. @@ -255,7 +255,7 @@ If name is not specified the short name of the Workflow interface is used. In the preceding code the `#[WorkflowMethod(name)]` is not specified, thus the Workflow Type defaults to `"FileProcessingWorkflow"`. -### How to handle a Query {#handle-query} +### How to handle a Query {/* #handle-query */} Queries are handled by your Workflow. @@ -350,15 +350,15 @@ sleep(60); var_dump($workflow->getCurrentState()); ``` -### How to send a Query {#send-query} +### How to send a Query {/* #send-query */} Queries are sent from a Temporal Client. -## How to develop with Updates {#updates} +## How to develop with Updates {/* #updates */} An [Update](/sending-messages#sending-updates) is an operation that can mutate the state of a Workflow Execution and return a response. -### Define Update {#define-update} +### Define Update {/* #define-update */} **How to define an Update using the PHP SDK.** @@ -377,7 +377,7 @@ The [`#[UpdateMethod]`](https://php.temporal.io/classes/Temporal-Workflow-Update public function myUpdate(string $value); ``` -### Handle Update {#handle-updates} +### Handle Update {/* #handle-updates */} **How to handle Updates in a Workflow using the PHP SDK.** @@ -428,7 +428,7 @@ Workflow::registerUpdate( ); ``` -### Validate Update {#validate-an-update} +### Validate Update {/* #validate-an-update */} **How to validate Updates in a Workflow using the PHP SDK.** @@ -448,7 +448,7 @@ interface GreetingWorkflow { } ``` -### Send Update from a Client {#send-update-from-client} +### Send Update from a Client {/* #send-update-from-client */} **How to send an Update to a Workflow Execution from a Temporal Client using the PHP SDK.** @@ -500,7 +500,7 @@ $resultUuid = $stub->startUpdate( )->getResult(); ``` -#### Update-With-Start {#update-with-start} +#### Update-With-Start {/* #update-with-start */} [Update-with-Start](/sending-messages#update-with-start) lets you [send an Update](#send-update-from-client) that checks whether an already-running Workflow with that ID exists: @@ -562,7 +562,7 @@ assert($handle->hasResult() === true); $price = $handle->getResult(); ``` -## Message handler patterns {#message-handler-patterns} +## Message handler patterns {/* #message-handler-patterns */} This section covers common write operations, such as Signal and Update handlers. It doesn't apply to pure read operations, like Queries or Update Validators. @@ -609,7 +609,7 @@ The `Workflow::await` method waits until your condition is met: Remember: Handlers can execute before the main Workflow method starts. -### Ensure your handlers finish before the Workflow completes {#wait-for-message-handlers} +### Ensure your handlers finish before the Workflow completes {/* #wait-for-message-handlers */} Workflow wait conditions can ensure your handler completes before a Workflow finishes. When your Workflow uses async Signal or Update handlers, your main Workflow method can return or continue-as-new while a handler is still waiting on an async task, such as an Activity result. @@ -698,7 +698,7 @@ Make sure to set this flag to `true` to enable the correct behavior. ::: -### Use `Mutex` to prevent concurrent handler execution {#control-handler-concurrency} +### Use `Mutex` to prevent concurrent handler execution {/* #control-handler-concurrency */} Concurrent processes can interact in unpredictable ways. Incorrectly written [concurrent message-passing](/handling-messages#message-handler-concurrency) code may not work correctly when multiple handler instances run simultaneously. @@ -765,7 +765,7 @@ class MyWorkflow } ``` -## Message handler troubleshooting {#message-handler-troubleshooting} +## Message handler troubleshooting {/* #message-handler-troubleshooting */} When sending a Signal, Update, or Query to a Workflow, your Client might encounter the following errors: @@ -782,7 +782,7 @@ When sending a Signal, Update, or Query to a Workflow, your Client might encount See [Exceptions in message handlers](/handling-messages#exceptions) for a non–PHP-specific discussion of this topic. -### Problems when sending a Signal {#signal-problems} +### Problems when sending a Signal {/* #signal-problems */} When using Signal, the only exception that will result from your requests during its execution is `ServiceClientException`. All handlers may experience additional exceptions during the initial (pre-Worker) part of a handler request lifecycle. @@ -790,7 +790,7 @@ All handlers may experience additional exceptions during the initial (pre-Worker For Queries and Updates, the client waits for a response from the Worker. If an issue occurs during the handler Execution by the Worker, the client may receive an exception. -### Problems when sending an Update {#update-problems} +### Problems when sending an Update {/* #update-problems */} When working with Updates, you may encounter these errors: @@ -828,7 +828,7 @@ These might include: - The Workflow completed normally or continued-as-new and the Workflow author did not [wait for handlers to be finished](/handling-messages#finishing-message-handlers). -### Problems when sending a Query {#query-problems} +### Problems when sending a Query {/* #query-problems */} When working with Queries, you may encounter these errors: @@ -843,7 +843,7 @@ When working with Queries, you may encounter these errors: - **The handler caused the Workflow Task to fail.** This would happen, for example, if the Query handler blocks the thread for too long without yielding. -## Dynamic components {#dynamic-handler} +## Dynamic components {/* #dynamic-handler */} Temporal supports Dynamic Queries, Signals, and Updates. These are unnamed handlers that are invoked if no other statically defined handler with the given name exists. @@ -863,7 +863,7 @@ They are meant to handle edge cases and act as a catch-all, not as the main way ::: -### How to set a Dynamic Query {#set-a-dynamic-query} +### How to set a Dynamic Query {/* #set-a-dynamic-query */} A Dynamic Query in Temporal is a Query method that is invoked dynamically at runtime if no other Query with the same name is registered. Use [`Workflow::registerDynamicQuery()`](https://php.temporal.io/classes/Temporal-Workflow.html#method_registerDynamicQuery) to set a dynamic Query handler. @@ -880,7 +880,7 @@ Workflow::registerDynamicQuery(function (string $name, ValuesInterface $argument }); ``` -### How to set a Dynamic Signal {#set-a-dynamic-signal} +### How to set a Dynamic Signal {/* #set-a-dynamic-signal */} A Dynamic Signal in Temporal is a Signal that is invoked dynamically at runtime if no other Signal with the same input is registered. Use [`Workflow::registerDynamicSignal()`](https://php.temporal.io/classes/Temporal-Workflow.html#method_registerDynamicSignal) to set a dynamic Signal handler. @@ -897,7 +897,7 @@ Workflow::registerDynamicSignal(function (string $name, ValuesInterface $argumen }); ``` -### How to set a Dynamic Update {#set-a-dynamic-update} +### How to set a Dynamic Update {/* #set-a-dynamic-update */} A Dynamic Update in Temporal is an Update that is invoked dynamically at runtime if no other Update with the same input is registered. Use [`Workflow::registerDynamicUpdate()`](https://php.temporal.io/classes/Temporal-Workflow.html#method_registerDynamicUpdate) to set a dynamic Update handler. diff --git a/docs/develop/php/workflows/schedules.mdx b/docs/develop/php/workflows/schedules.mdx index cfddd3c871..b34998bdde 100644 --- a/docs/develop/php/workflows/schedules.mdx +++ b/docs/develop/php/workflows/schedules.mdx @@ -19,7 +19,7 @@ This page shows how to do the following: - [How to use Start Delay](#start-delay) - [How to use Temporal Cron Jobs](#temporal-cron-jobs) -## How to use Start Delay {#start-delay} +## How to use Start Delay {/* #start-delay */} Use the Workflow [Start Delay](/workflow-execution/timers-delays) functionality if you need to delay the execution of the Workflow without the need for regular launches. Here you simply specify the time to wait before dispatching the first Workflow task. @@ -33,7 +33,7 @@ $workflow = $workflowClient->newWorkflowStub( $workflowClient->start($workflow, 'Hello world!'); ``` -## How to use Temporal Cron Jobs {#temporal-cron-jobs} +## How to use Temporal Cron Jobs {/* #temporal-cron-jobs */} :::caution Cron support is not recommended diff --git a/docs/develop/php/workflows/side-effects.mdx b/docs/develop/php/workflows/side-effects.mdx index c10a26605b..4f95b4e648 100644 --- a/docs/develop/php/workflows/side-effects.mdx +++ b/docs/develop/php/workflows/side-effects.mdx @@ -13,7 +13,7 @@ tags: description: Use Side Effects in PHP to execute non-deterministic code like generating UUIDs or random numbers in a Workflow without compromising its determinism. --- -## How to use Side Effects in PHP {#side-effects} +## How to use Side Effects in PHP {/* #side-effects */} Side Effects are used to execute non-deterministic code, such as generating a UUID or a random number, without compromising determinism in the Workflow. This is done by storing the results of the Side Effect into the Workflow [Event History](/workflow-execution/event#event-history). diff --git a/docs/develop/php/workflows/timeouts.mdx b/docs/develop/php/workflows/timeouts.mdx index 71ae569e90..a3d518a88a 100644 --- a/docs/develop/php/workflows/timeouts.mdx +++ b/docs/develop/php/workflows/timeouts.mdx @@ -17,7 +17,7 @@ tags: - Temporal SDKs --- -## Workflow timeouts {#workflow-timeouts} +## Workflow timeouts {/* #workflow-timeouts */} Each Workflow timeout controls the maximum duration of a different aspect of a Workflow Execution. @@ -52,7 +52,7 @@ $workflow = $this->workflowClient->newWorkflowStub( ); ``` -### Workflow retries {#workflow-retries} +### Workflow retries {/* #workflow-retries */} A Retry Policy can work in cooperation with the timeouts to provide fine controls to optimize the execution experience. diff --git a/docs/develop/php/workflows/timers.mdx b/docs/develop/php/workflows/timers.mdx index e0570a757e..2c3159d5f7 100644 --- a/docs/develop/php/workflows/timers.mdx +++ b/docs/develop/php/workflows/timers.mdx @@ -14,7 +14,7 @@ tags: description: A Timer in a Workflow sets a durable pause for a fixed time. Even after downtimes, your Workflow resumes execution. Lightweight and scalable, millions of Timers can run on a single Worker. --- -## What is a Timer? {#timers} +## What is a Timer? {/* #timers */} A Workflow can set a durable timer for a fixed time period. In some SDKs, the function is called `sleep()`, and in others, it's called `timer()`. diff --git a/docs/develop/php/workflows/versioning.mdx b/docs/develop/php/workflows/versioning.mdx index 0b78c46e5f..d720810e2b 100644 --- a/docs/develop/php/workflows/versioning.mdx +++ b/docs/develop/php/workflows/versioning.mdx @@ -41,7 +41,7 @@ There are two primary Versioning methods that you can use: Temporal's [Worker Versioning](/production-deployment/worker-deployments/worker-versioning) feature allows you to tag your Workers and programmatically roll them out in Deployment Versions, so that old Workers can run old code paths and new Workers can run new code paths. This way, you can pin your Workflows to specific revisions, avoiding the need for patching. -## Versioning with Patching {#php-sdk-patching-api} +## Versioning with Patching {/* #php-sdk-patching-api */} ### Patching with GetVersion @@ -184,7 +184,7 @@ The downside of this method is that it requires you to duplicate code and to upd This can become impractical over time. This method also does not provide a way to version any still-running Workflows -- it is essentially just a cutover, unlike Patching. -## Runtime checking {#runtime-checking} +## Runtime checking {/* #runtime-checking */} The Temporal PHP SDK performs a runtime check to help prevent obvious incompatible changes. Adding, removing, or reordering any of these methods without Versioning triggers the runtime check and results in a nondeterminism error: diff --git a/docs/develop/plugins-guide.mdx b/docs/develop/plugins-guide.mdx index 2ee78cace2..c9e3158fcc 100644 --- a/docs/develop/plugins-guide.mdx +++ b/docs/develop/plugins-guide.mdx @@ -814,7 +814,7 @@ plugin = Temporalio::SimplePlugin.new( -### Context Propagators {#context-propagators} +### Context Propagators {/* #context-propagators */} Context propagators pass custom key-value data (such as tracing IDs, tenant IDs, or auth tokens) across Workflow, Activity, and Child Workflow boundaries via Temporal headers. See [Context Propagation](/encyclopedia/context-propagation) for details on how they work. @@ -891,7 +891,7 @@ const worker = await Worker.create({ ``` {/* SNIPEND */} -## Testing your Plugin {#testing-your-plugin} +## Testing your Plugin {/* #testing-your-plugin */} To test your Plugin, you'll write a normal Temporal Workflow tests, having included the plugin in your Client. diff --git a/docs/develop/python/activities/basics.mdx b/docs/develop/python/activities/basics.mdx index 46223f687a..ffec74c9ca 100644 --- a/docs/develop/python/activities/basics.mdx +++ b/docs/develop/python/activities/basics.mdx @@ -11,7 +11,7 @@ tags: - Temporal SDKs --- -## Develop a basic Activity {#develop-activities} +## Develop a basic Activity {/* #develop-activities */} **How to develop a basic Activity using the Temporal Python SDK.** @@ -62,7 +62,7 @@ async def your_activity(input: YourParams) -> str: return f"{input.greeting}, {input.name}!" ``` -### Develop Activity Parameters {#activity-parameters} +### Develop Activity Parameters {/* #activity-parameters */} **How to develop Activity Parameters using the Temporal Python SDK.** @@ -106,7 +106,7 @@ async def your_activity(input: YourParams) -> str: return f"{input.greeting}, {input.name}!" ``` -### Define Activity return values {#activity-return-values} +### Define Activity return values {/* #activity-return-values */} **How to define Activity return values using the Temporal Python SDK.** @@ -135,7 +135,7 @@ async def your_activity(input: YourParams) -> str: return f"{input.greeting}, {input.name}!" ``` -### Customize your Activity Type {#activity-type} +### Customize your Activity Type {/* #activity-type */} **How to customize your Activity Type** diff --git a/docs/develop/python/activities/execution.mdx b/docs/develop/python/activities/execution.mdx index 6a3c4632ac..4e18d1a940 100644 --- a/docs/develop/python/activities/execution.mdx +++ b/docs/develop/python/activities/execution.mdx @@ -11,7 +11,7 @@ tags: - Activity --- -## Start an Activity Execution {#activity-execution} +## Start an Activity Execution {/* #activity-execution */} **How to start an Activity Execution using the Temporal Python SDK.** @@ -70,7 +70,7 @@ class YourWorkflow: ) ``` -### Set the required Activity Timeouts {#required-timeout} +### Set the required Activity Timeouts {/* #required-timeout */} **How to set the required Activity Timeouts using the Temporal Python SDK.** @@ -106,7 +106,7 @@ Available timeouts are: ) ``` -### Get the results of an Activity Execution {#get-activity-results} +### Get the results of an Activity Execution {/* #get-activity-results */} **How to get the results of an Activity Execution using the Temporal Python SDK.** diff --git a/docs/develop/python/activities/standalone-activities.mdx b/docs/develop/python/activities/standalone-activities.mdx index da68fdf5bd..16d3ebb698 100644 --- a/docs/develop/python/activities/standalone-activities.mdx +++ b/docs/develop/python/activities/standalone-activities.mdx @@ -52,7 +52,7 @@ This documentation uses source code from the [hello_standalone_activity](https:/ ::: -## Get Started with Standalone Activities {#get-started} +## Get Started with Standalone Activities {/* #get-started */} Prerequisites: @@ -134,7 +134,7 @@ hello_standalone_activity/ └── count_activities.py ``` -## Write an Activity Function {#write-activity} +## Write an Activity Function {/* #write-activity */} An Activity in the Temporal Python SDK is just a normal function with the `@activity.defn` decorator. It can optionally be an `async def`. The way you write a Standalone Activity is identical @@ -162,7 +162,7 @@ def compose_greeting(input: ComposeGreetingInput) -> str: return f"{input.greeting}, {input.name}!" ``` -## Run a Worker with the Activity registered {#run-worker} +## Run a Worker with the Activity registered {/* #run-worker */} Running a Worker for Standalone Activities is the same as running a Worker for Workflow Activities — you create a Worker, register the Activity, and run the Worker. The Worker doesn't need to know @@ -209,7 +209,7 @@ uv run hello_standalone_activity/worker.py Leave this terminal running - the Worker needs to stay up to process activities. -## Execute a Standalone Activity {#execute-activity} +## Execute a Standalone Activity {/* #execute-activity */} Use [`client.execute_activity()`](https://python.temporal.io/temporalio.client.Client.html#execute_activity) @@ -270,7 +270,7 @@ temporal activity execute \ ``` -## Start a Standalone Activity without waiting for the result {#start-activity} +## Start a Standalone Activity without waiting for the result {/* #start-activity */} Starting a Standalone Activity means sending a request to the Temporal Server to durably enqueue your Activity job, without waiting for it to be executed by your Worker. @@ -306,7 +306,7 @@ temporal activity start \ --input '{"greeting": "Hello", "name": "World"}' ``` -## Get a handle to an existing Standalone Activity {#get-activity-handle} +## Get a handle to an existing Standalone Activity {/* #get-activity-handle */} You can also use `client.get_activity_handle()` to create a handle to a previously started Standalone Activity: @@ -319,7 +319,7 @@ activity_handle = client.get_activity_handle( You can now use the handle to wait for the result, describe, cancel, or terminate the Activity. -## Wait for the result of a Standalone Activity {#get-activity-result} +## Wait for the result of a Standalone Activity {/* #get-activity-result */} Under the hood, calling `client.execute_activity()` is the same as calling [`client.start_activity()`](https://python.temporal.io/temporalio.client.Client.html#start_activity) @@ -336,7 +336,7 @@ Or use the Temporal CLI to wait for a result by Activity ID: temporal activity result --activity-id my-standalone-activity-id ``` -## List Standalone Activities {#list-activities} +## List Standalone Activities {/* #list-activities */} Use [`client.list_activities()`](https://python.temporal.io/temporalio.client.Client.html#list_activities) @@ -389,7 +389,7 @@ The query parameter accepts the same [List Filter](/list-filter) syntax used for Visibility](/visibility). For example, "ActivityType = 'MyActivity' AND Status = 'Running'". -## Count Standalone Activities {#count-activities} +## Count Standalone Activities {/* #count-activities */} Use [`client.count_activities()`](https://python.temporal.io/temporalio.client.Client.html#count_activities) to count Standalone Activity Executions that match a [List Filter](/list-filter) query. This returns the total @@ -436,7 +436,7 @@ Or use the Temporal CLI: temporal activity count ``` -## Run Standalone Activities with Temporal Cloud {#run-standalone-activities-temporal-cloud} +## Run Standalone Activities with Temporal Cloud {/* #run-standalone-activities-temporal-cloud */} The code samples on this page use `ClientConfig.load_client_connect_config()`, so the same code works against Temporal Cloud - just configure the connection via environment variables or a TOML diff --git a/docs/develop/python/activities/timeouts.mdx b/docs/develop/python/activities/timeouts.mdx index a5c1b41720..65b01776a3 100644 --- a/docs/develop/python/activities/timeouts.mdx +++ b/docs/develop/python/activities/timeouts.mdx @@ -17,7 +17,7 @@ tags: - Temporal SDKs --- -## Set Activity timeouts {#activity-timeouts} +## Set Activity timeouts {/* #activity-timeouts */} Each Activity timeout controls the maximum duration of a different aspect of an Activity Execution. @@ -56,7 +56,7 @@ Available timeouts are: ) ``` -### Set an Activity Retry Policy {#activity-retries} +### Set an Activity Retry Policy {/* #activity-retries */} **How to set an Activity Retry Policy using the Temporal Python SDK** @@ -91,7 +91,7 @@ from temporalio.common import RetryPolicy ) ``` -### Override the retry interval with `next_retry_delay` {#next-retry-delay} +### Override the retry interval with `next_retry_delay` {/* #next-retry-delay */} To override the next retry interval set by the current policy, pass `next_retry_delay` when raising an [ApplicationError](/references/failures#application-failure) in an Activity. This value replaces and overrides whatever the retry interval would normally be on the retry policy. @@ -117,7 +117,7 @@ async def my_activity(input: MyActivityInput): ) from e ``` -## Heartbeat an Activity {#activity-heartbeats} +## Heartbeat an Activity {/* #activity-heartbeats */} **How to Heartbeat an Activity using the Temporal Python SDK** @@ -144,7 +144,7 @@ async def your_activity_definition() -> str: In addition to obtaining cancellation information, Heartbeats also support detail data that persists on the server for retrieval during Activity retry. If an Activity calls `heartbeat(123, 456)` and then fails and is retried, `heartbeat_details` returns an iterable containing `123` and `456` on the next Run. -#### Set a Heartbeat Timeout {#heartbeat-timeout} +#### Set a Heartbeat Timeout {/* #heartbeat-timeout */} **How to set a Heartbeat Timeout using the Temporal Python SDK** diff --git a/docs/develop/python/best-practices/debugging.mdx b/docs/develop/python/best-practices/debugging.mdx index 305c08bf9b..24119eaced 100644 --- a/docs/develop/python/best-practices/debugging.mdx +++ b/docs/develop/python/best-practices/debugging.mdx @@ -24,14 +24,14 @@ This page shows how to do the following: - [Debug in a development environment](#debug-in-a-development-environment) - [Debug in a production environment](#debug-in-a-production-environment) -### Debug in a development environment {#debug-in-a-development-environment} +### Debug in a development environment {/* #debug-in-a-development-environment */} **How to debug in a development environment using the Temporal Python SDK.** When developing Workflows, you can use the normal development tools of logging and a debugger to see what’s happening in your Workflow. 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 production environment {#debug-in-a-production-environment} +### How to debug in a production environment {/* #debug-in-a-production-environment */} **How to debug in a production environment using the Temporal Python SDK.** diff --git a/docs/develop/python/best-practices/error-handling.mdx b/docs/develop/python/best-practices/error-handling.mdx index 530f3fb868..af3fb366ca 100644 --- a/docs/develop/python/best-practices/error-handling.mdx +++ b/docs/develop/python/best-practices/error-handling.mdx @@ -45,7 +45,7 @@ This page shows how to: - [Implement rollback logic with the Saga pattern](#implement-saga-pattern) - [Understand Temporal's failure types](#understand-failure-types) -## Make Activities idempotent {#make-activities-idempotent} +## Make Activities idempotent {/* #make-activities-idempotent */} **How to make Activities idempotent using the Temporal Python SDK** @@ -95,7 +95,7 @@ Consider this Activity: If step 3 fails, all three steps execute again on retry. You might split this into three separate Activities so only the failed step retries, but balance this against having a larger Event History with more Activity Executions. -## Raise exceptions from Activities {#raise-exceptions-from-activities} +## Raise exceptions from Activities {/* #raise-exceptions-from-activities */} **How to raise exceptions from Activities using the Temporal Python SDK** @@ -139,7 +139,7 @@ The `ActivityError` provides context including: - Number of retry attempts - Original cause (the [`ApplicationError`](https://python.temporal.io/temporalio.exceptions.ApplicationError.html) you raised, or `TimeoutError`, [`CancelledError`](https://python.temporal.io/temporalio.exceptions.CancelledError.html), etc.) -## Raise exceptions from Workflows {#raise-exceptions-from-workflows} +## Raise exceptions from Workflows {/* #raise-exceptions-from-workflows */} **How to raise exceptions from Workflows using the Temporal Python SDK** @@ -193,7 +193,7 @@ This is intentional. Regular Python exceptions are treated as bugs that can be fixed with a code deployment, not business logic failures. The Workflow Task retries indefinitely, letting you fix the bug and redeploy without losing Workflow state. -## Handle exceptions in Workflows {#handle-exceptions-in-workflows} +## Handle exceptions in Workflows {/* #handle-exceptions-in-workflows */} **How to handle exceptions in Workflows using the Temporal Python SDK** @@ -257,7 +257,7 @@ Common Temporal exceptions you can catch in Workflows: If these exceptions propagate unhandled, the Workflow Execution fails (or enters "Canceled" state for `CancelledError`). -## Configure custom Retry Policies {#configure-custom-retry-policies} +## Configure custom Retry Policies {/* #configure-custom-retry-policies */} **How to configure custom Retry Policies using the Temporal Python SDK** @@ -345,7 +345,7 @@ A Workflow failure typically indicates a code bug or bad input data—retrying t If you need retry logic for specific Workflow operations, implement it in your Workflow code rather than using a Workflow Retry Policy. -## Mark specific errors as non-retryable {#mark-errors-as-non-retryable} +## Mark specific errors as non-retryable {/* #mark-errors-as-non-retryable */} **How to mark specific errors as non-retryable using the Temporal Python SDK** @@ -389,7 +389,7 @@ Use non-retryable errors for: **Use this sparingly.** In most cases, it's better to let the Retry Policy handle when to stop retrying based on time or attempts. -## Specify non-retryable error types {#specify-non-retryable-error-types} +## Specify non-retryable error types {/* #specify-non-retryable-error-types */} **How to specify non-retryable error types in Retry Policies using the Temporal Python SDK** @@ -438,7 +438,7 @@ This enforces the constraint for all callers. **`non_retryable_error_types` in the Retry Policy**: Use when the caller wants to decide which errors are unrecoverable based on their business logic. This lets different Workflows make different decisions about the same Activity. -## Implement rollback logic with the Saga pattern {#implement-saga-pattern} +## Implement rollback logic with the Saga pattern {/* #implement-saga-pattern */} **How to implement the Saga pattern using the Temporal Python SDK** @@ -525,7 +525,7 @@ Key points: - Handle compensation failures gracefully (they might fail too) - Temporal manages all state and retry logic, making Saga implementation straightforward -## Understand Temporal's failure types {#understand-failure-types} +## Understand Temporal's failure types {/* #understand-failure-types */} Temporal uses specialized exception types to represent different failure scenarios. All exceptions inherit from [`TemporalError`](https://python.temporal.io/temporalio.exceptions.TemporalError.html). diff --git a/docs/develop/python/best-practices/testing-suite.mdx b/docs/develop/python/best-practices/testing-suite.mdx index 1391a780dd..aee216ed61 100644 --- a/docs/develop/python/best-practices/testing-suite.mdx +++ b/docs/develop/python/best-practices/testing-suite.mdx @@ -30,18 +30,18 @@ We generally recommend writing the majority of your tests as integration tests. Because the test server supports skipping time, use the test server for both end-to-end and integration tests with Workers. -## Test frameworks {#test-frameworks} +## Test frameworks {/* #test-frameworks */} Some SDKs have support or examples for popular test frameworks, runners, or libraries. One recommended framework for testing in Python for the Temporal SDK is [pytest](https://docs.pytest.org/), which can help with fixtures to stand up and tear down test environments, provide useful test discovery, and make it easy to write parameterized tests. -## Testing Activities {#test-activities} +## Testing Activities {/* #test-activities */} An Activity can be tested with a mock Activity environment, which provides a way to mock the Activity context, listen to Heartbeats, and cancel the Activity. This behavior allows you to test the Activity in isolation by calling it directly, without needing to create a Worker to run the Activity. -### Run an Activity {#run-an-activity} +### Run an Activity {/* #run-an-activity */} If an Activity references its context, you need to mock that context when testing in isolation. @@ -50,7 +50,7 @@ To run an Activity in a test, use the [`ActivityEnvironment`](https://python.tem This class allows you to run any callable inside an Activity context. Use it to test the behavior of your code under various conditions. -### Listen to Heartbeats {#listen-to-heartbeats} +### Listen to Heartbeats {/* #listen-to-heartbeats */} When an Activity sends a Heartbeat, be sure that you can see the Heartbeats in your test code so that you can verify them. @@ -73,9 +73,9 @@ await env.run(activity_with_heartbeats, "test") assert heartbeats == ["param: test", "second heartbeat"] ``` -## Testing Workflows {#test-workflows} +## Testing Workflows {/* #test-workflows */} -### How to mock Activities {#mock-activities} +### How to mock Activities {/* #mock-activities */} Mock the Activity invocation when unit testing your Workflows. @@ -121,7 +121,7 @@ async def test_mock_activity(client: Client): The mocked Activity implementation should have the same signature as the real implementation (including the input and output types) and the same name. When the Workflow invokes the Activity, it invokes the mocked implementation instead of the real one, allowing you to test your Workflow isolated. -### How to skip time {#skip-time} +### How to skip time {/* #skip-time */} Some long-running Workflows can persist for months or even years. Implementing the test framework allows your Workflow code to skip time and complete your tests in seconds rather than the Workflow's specified amount. @@ -134,7 +134,7 @@ Time is a global property of an instance of `TestWorkflowEnvironment`: skipping If you need different time behaviors for different tests, run your tests in a series or with separate instances of the test server. For example, you could run all tests with automatic time skipping in parallel, and then all tests with manual time skipping in series, and then all tests without time skipping in parallel. -#### Skip time automatically {#automatic-method} +#### Skip time automatically {/* #automatic-method */} You can skip time automatically in the SDK of your choice. Start a test server process that skips time as needed. @@ -146,7 +146,7 @@ Use the [`start_local()`](https://python.temporal.io/temporalio.testing.Workflow Use the [`from_client()`](https://python.temporal.io/temporalio.testing.WorkflowEnvironment.html#from_client) method for an existing Temporal Server. -#### Skip time manually {#manual-method} +#### Skip time manually {/* #manual-method */} Skip time manually in the SDK of your choice. @@ -163,7 +163,7 @@ async def test_manual_time_skipping(): # Your code here ``` -### Assert in Workflow {#assert-in-workflow} +### Assert in Workflow {/* #assert-in-workflow */} The `assert` statement is a convenient way to insert debugging assertions into the Workflow context. @@ -171,7 +171,7 @@ The `assert` method is available in Python and TypeScript. For information about assert statements in Python, see [`assert`](https://docs.python.org/3/reference/simple_stmts.html#the-assert-statement) in the Python Language Reference. -## How to Replay a Workflow Execution {#replay} +## How to Replay a Workflow Execution {/* #replay */} Replay recreates the exact state of a Workflow Execution. You can replay a Workflow from the beginning of its Event History. diff --git a/docs/develop/python/client/temporal-client.mdx b/docs/develop/python/client/temporal-client.mdx index 3582acbd01..30bc41d50f 100644 --- a/docs/develop/python/client/temporal-client.mdx +++ b/docs/develop/python/client/temporal-client.mdx @@ -42,7 +42,7 @@ This page shows you how to do the following using the Python SDK with the Tempor A Temporal Client cannot be initialized and used inside a Workflow. However, it is acceptable and common to use a Temporal Client inside an Activity to communicate with a Temporal Service. -## Connect to development Temporal Service {#connect-to-development-service} +## Connect to development Temporal Service {/* #connect-to-development-service */} Use [`Client.connect`](https://python.temporal.io/temporalio.client.Client.html#connect) to create a client. Connection options include the Temporal Server address, Namespace, and (optionally) TLS configuration. You can provide these @@ -249,7 +249,7 @@ if __name__ == "__main__": -## Connect to Temporal Cloud {#connect-to-temporal-cloud} +## Connect to Temporal Cloud {/* #connect-to-temporal-cloud */} You can connect to Temporal Cloud using either an [API key](/cloud/api-keys) or through mTLS. Connection to Temporal Cloud or any secured Temporal Service requires additional connection options compared to connecting to an unsecured @@ -480,7 +480,7 @@ For more information about configuring TLS to secure inter- and intra-network co -## Start a Workflow Execution {#start-workflow-execution} +## Start a Workflow Execution {/* #start-workflow-execution */} **How to start a Workflow Execution using the Python SDK** @@ -531,7 +531,7 @@ if __name__ == "__main__": asyncio.run(main()) ``` -### Set a Workflow's Task Queue {#set-task-queue} +### Set a Workflow's Task Queue {/* #set-task-queue */} **How to set a Workflow's Task Queue using the Python SDK** @@ -570,7 +570,7 @@ if __name__ == "__main__": asyncio.run(main()) ``` -### Set a Workflow Id {#workflow-id} +### Set a Workflow Id {/* #workflow-id */} **How to set a Workflow Id using the Python SDK** @@ -611,7 +611,7 @@ if __name__ == "__main__": asyncio.run(main()) ``` -### Get the results of a Workflow Execution {#get-workflow-results} +### Get the results of a Workflow Execution {/* #get-workflow-results */} **How to get the results of a Workflow Execution using the Python SDK** diff --git a/docs/develop/python/nexus/feature-guide.mdx b/docs/develop/python/nexus/feature-guide.mdx index df9c0ffbd2..f484adefa2 100644 --- a/docs/develop/python/nexus/feature-guide.mdx +++ b/docs/develop/python/nexus/feature-guide.mdx @@ -45,7 +45,7 @@ This documentation uses source code derived from the [Python Nexus sample](https ::: -## Run the Temporal Development Server with Nexus enabled {#run-the-temporal-nexus-development-server} +## Run the Temporal Development Server with Nexus enabled {/* #run-the-temporal-nexus-development-server */} Prerequisites: @@ -62,7 +62,7 @@ This command automatically starts the Temporal development server with the Web U The Temporal Web UI should now be accessible at [http://localhost:8233](http://localhost:8233), and the Temporal Server should now be available for client connections on `localhost:7233`. -## Create caller and handler Namespaces {#create-caller-handler-namespaces} +## Create caller and handler Namespaces {/* #create-caller-handler-namespaces */} Before setting up Nexus endpoints, create separate Namespaces for the caller and handler. @@ -74,7 +74,7 @@ temporal operator namespace create --namespace my-caller-namespace For this example, `my-target-namespace` will contain the Nexus Operation handler, and you will use a Workflow in `my-caller-namespace` to call that Operation handler. We use different namespaces to demonstrate cross-Namespace Nexus calls. -## Create a Nexus Endpoint to route requests from caller to handler {#create-nexus-endpoint} +## Create a Nexus Endpoint to route requests from caller to handler {/* #create-nexus-endpoint */} After establishing caller and handler Namespaces, the next step is to create a Nexus Endpoint to route requests. @@ -87,7 +87,7 @@ temporal operator nexus endpoint create \ You can also use the Web UI to create the Namespaces and Nexus endpoint. -## Define the Nexus Service contract {#define-nexus-service-contract} +## Define the Nexus Service contract {/* #define-nexus-service-contract */} Defining a clear contract for the Nexus Service is crucial for smooth communication. @@ -122,7 +122,7 @@ class MyNexusService: my_workflow_run_operation: nexusrpc.Operation[MyInput, MyOutput] ``` -## Develop a Nexus Service handler and Operation handlers {#develop-nexus-service-operation-handlers} +## Develop a Nexus Service handler and Operation handlers {/* #develop-nexus-service-operation-handlers */} Nexus Operation handlers are typically defined in the same Worker as the underlying Temporal primitives they abstract. Operation handlers can decide if a given Nexus Operation will be synchronous or asynchronous. @@ -281,7 +281,7 @@ async def main(): await worker.run() ``` -## Develop a caller Workflow that uses the Nexus Service {#develop-caller-workflow-nexus-service} +## Develop a caller Workflow that uses the Nexus Service {/* #develop-caller-workflow-nexus-service */} To execute a Nexus Operation from the caller Workflow, import the necessary service definition and operation input/output types: @@ -326,7 +326,7 @@ These steps are the same as for any normal Workflow. The Python sample combines them in a single application. See [hello_nexus/caller/app.py](https://github.com/temporalio/samples-python/blob/main/hello_nexus/caller/app.py) for reference. -## Exceptions in Nexus operations {#exceptions-in-nexus-operations} +## Exceptions in Nexus operations {/* #exceptions-in-nexus-operations */} Temporal provides general guidance on [Errors in Nexus operations](https://docs.temporal.io/references/failures#errors-in-nexus-operations). In Python, there are three Nexus-specific exception classes: @@ -335,7 +335,7 @@ In Python, there are three Nexus-specific exception classes: - [`nexusrpc.HandlerError`](https://nexus-rpc.github.io/sdk-python/nexusrpc.HandlerError.html): you can raise this exception type in a Nexus operation with a specific [HandlerErrorType](https://nexus-rpc.github.io/sdk-python/nexusrpc.HandlerErrorType.html). The error will be marked retryable or non-retryable according to the type, following the [Nexus spec](https://github.com/nexus-rpc/api/blob/main/SPEC.md#predefined-handler-errors). The non-retryable handler error types are `BAD_REQUEST`, `UNAUTHENTICATED`, `UNAUTHORIZED`, `NOT_FOUND`, `NOT_IMPLEMENTED`; the retryable types are `RESOURCE_EXHAUSTED`, `INTERNAL`, `UNAVAILABLE`, `UPSTREAM_TIMEOUT`. - [`temporalio.exceptions.NexusOperationError`](https://python.temporal.io/temporalio.exceptions.NexusOperationError.html): this is the error raised inside a Workflow when a Nexus operation fails for any reason. Use the `__cause__` attribute on the exception to access the cause chain. -## Canceling a Nexus Operation {#canceling-a-nexus-operation} +## Canceling a Nexus Operation {/* #canceling-a-nexus-operation */} To cancel a Nexus Operation from within a Workflow, call `handle.cancel()` on the operation handle. Only asynchronous operations can be canceled in Nexus, since cancellation is sent using an operation token. The Workflow or other resources backing the operation may choose to ignore the cancellation request. @@ -356,7 +356,7 @@ To ensure cancellations are delivered, wait for all pending operations to finish See the [Nexus cancellation sample](https://github.com/temporalio/samples-python/tree/main/nexus_cancel) for reference. -## Make Nexus calls across Namespaces in Temporal Cloud {#nexus-calls-across-namespaces-temporal-cloud} +## 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. 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. diff --git a/docs/develop/python/platform/observability.mdx b/docs/develop/python/platform/observability.mdx index 026365fbfa..03d51c58f4 100644 --- a/docs/develop/python/platform/observability.mdx +++ b/docs/develop/python/platform/observability.mdx @@ -33,7 +33,7 @@ This section covers features related to viewing the state of the application, in - [Log from a Workflow](#logging) - [Visibility APIs](#visibility) -## Emit metrics {#metrics} +## Emit metrics {/* #metrics */} **How to emit metrics** @@ -57,7 +57,7 @@ new_runtime = Runtime(telemetry=TelemetryConfig(metrics=PrometheusConfig(bind_ad my_client = await Client.connect("my.temporal.host:7233", runtime=new_runtime) ``` -## Set up tracing {#tracing} +## Set up tracing {/* #tracing */} **How to set up tracing** @@ -77,7 +77,7 @@ Then the [`temporalio.contrib.opentelemetry.TracingInterceptor`](https://python. When your Client is connected, spans are created for all Client calls, Activities, and Workflow invocations on the Worker. Spans are created and serialized through the server to give one trace for a Workflow Execution. -## Log from a Workflow {#logging} +## Log from a Workflow {/* #logging */} Logging enables you to record critical information during code execution. Loggers create an audit trail and capture information about your Workflow's operation. @@ -126,17 +126,17 @@ Then in your Workflow, set your [`logger`](https://python.temporal.io/temporalio workflow.logger.info("Workflow input parameter: %s" % name) ``` -### Custom logger {#custom-logger} +### Custom logger {/* #custom-logger */} Use a custom logger for logging. Use the built-in [Logging facility for Python](https://docs.python.org/3/library/logging.html) to set a custom logger. -## Visibility APIs {#visibility} +## Visibility APIs {/* #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 Temporal Service. -### Use Search Attributes {#search-attributes} +### Use Search Attributes {/* #search-attributes */} The typical method of retrieving a Workflow Execution is by its Workflow Id. @@ -180,7 +180,7 @@ Use the [list_workflows()](https://python.temporal.io/temporalio.client.Client.h print(f"Workflow: {workflow.id}") ``` -### How to set custom Search Attributes {#custom-search-attributes} +### How to set custom Search Attributes {/* #custom-search-attributes */} After you've created custom Search Attributes in your Temporal Service (using `temporal operator search-attribute create` or the Cloud UI), you can set the values of the custom Search Attributes when starting a Workflow. @@ -205,7 +205,7 @@ handle = await client.start_workflow( In this example, `CustomerId` and `MiscData` are set as Search Attributes. These attributes are useful for querying Workflows based on the customer ID or the date the order was placed. -### Upsert Search Attributes {#upsert-search-attributes} +### Upsert Search Attributes {/* #upsert-search-attributes */} You can upsert Search Attributes to add or update Search Attributes from within Workflow code. @@ -218,7 +218,7 @@ workflow.upsert_search_attributes([ ]) ``` -### Remove a Search Attribute from a Workflow {#remove-search-attribute} +### Remove a Search Attribute from a Workflow {/* #remove-search-attribute */} To remove a Search Attribute that was previously set, use `value_unset call` on the Search Attribute key. diff --git a/docs/develop/python/workers/interceptors.mdx b/docs/develop/python/workers/interceptors.mdx index e5616678d8..4e28cc05f9 100644 --- a/docs/develop/python/workers/interceptors.mdx +++ b/docs/develop/python/workers/interceptors.mdx @@ -47,7 +47,7 @@ Activity and Client interceptors are not affected by replay. ::: -## Register an Interceptor {#register} +## Register an Interceptor {/* #register */} Registering an interceptor means supplying an interceptor instance to the SDK so Temporal can invoke it when matching Client or Worker calls occur. Once registered, the interceptor runs as part of the call path and can observe or modify diff --git a/docs/develop/python/workers/run-process.mdx b/docs/develop/python/workers/run-process.mdx index cced009172..9c72bf47a7 100644 --- a/docs/develop/python/workers/run-process.mdx +++ b/docs/develop/python/workers/run-process.mdx @@ -11,7 +11,7 @@ tags: - Worker --- -## Run a Worker Process {#run-a-dev-worker} +## Run a Worker Process {/* #run-a-dev-worker */} **How to run a Worker Process using the Temporal Python SDK.** @@ -62,7 +62,7 @@ if __name__ == "__main__": asyncio.run(main()) ``` -### Register types {#register-types} +### Register types {/* #register-types */} **How to register types using the Temporal Python SDK.** diff --git a/docs/develop/python/workers/serverless-workers/aws-lambda.mdx b/docs/develop/python/workers/serverless-workers/aws-lambda.mdx index 96ab59a134..b8879da487 100644 --- a/docs/develop/python/workers/serverless-workers/aws-lambda.mdx +++ b/docs/develop/python/workers/serverless-workers/aws-lambda.mdx @@ -35,7 +35,7 @@ You register Workflows and Activities the same way you would with a standard Wor For a full end-to-end deployment guide covering AWS IAM setup, compute configuration, and verification, see [Deploy a Serverless Worker](/production-deployment/worker-deployments/serverless-workers). -## Create and run a Worker in Lambda {#create-and-run} +## Create and run a Worker in Lambda {/* #create-and-run */} Use the `run_worker` function to create a Lambda handler that runs a Temporal Worker. Pass a `WorkerDeploymentVersion` and a configure callback that registers your Workflows and Activities. @@ -87,7 +87,7 @@ class MyWorkflow: ... ``` -## Configure the Temporal connection {#configure-connection} +## Configure the Temporal connection {/* #configure-connection */} The `lambda_worker` package automatically loads Temporal client configuration from a TOML config file and environment variables. Refer to [Environment Configuration](/develop/environment-configuration) for more details. @@ -101,7 +101,7 @@ The file is optional. If absent, only environment variables are used. Encrypt sensitive values like TLS keys or API keys. Refer to [AWS documentation](https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars-encryption.html) for options. -## Adjust Worker defaults for Lambda {#lambda-tuned-defaults} +## Adjust Worker defaults for Lambda {/* #lambda-tuned-defaults */} The `lambda_worker` package applies conservative defaults suited to short-lived Lambda invocations. These differ from standard Worker defaults to avoid overcommitting resources in a constrained environment. @@ -130,7 +130,7 @@ The default is `graceful_shutdown_timeout` + 2 seconds. If your Worker handles long-running Activities, increase `graceful_shutdown_timeout`, `shutdown_deadline_buffer`, and the Lambda invocation deadline (`--timeout`) together. For guidance on how these values relate, see [Tuning for long-running Activities](/serverless-workers#tuning-for-long-running-activities). -## Add observability with OpenTelemetry {#add-observability} +## Add observability with OpenTelemetry {/* #add-observability */} The `lambda_worker.otel` module provides OpenTelemetry integration with defaults configured for the [AWS Distro for OpenTelemetry (ADOT)](https://aws-otel.github.io/docs/getting-started/lambda) Lambda layer. With this enabled, the Worker emits SDK metrics and distributed traces for Workflow and Activity executions. diff --git a/docs/develop/python/workflows/basics.mdx b/docs/develop/python/workflows/basics.mdx index d0f1eeefc5..b91db46f9f 100644 --- a/docs/develop/python/workflows/basics.mdx +++ b/docs/develop/python/workflows/basics.mdx @@ -11,7 +11,7 @@ tags: - Temporal SDKs --- -## Develop a basic Workflow {#develop-workflows} +## Develop a basic Workflow {/* #develop-workflows */} **How to develop a basic Workflow using the Temporal Python SDK.** @@ -47,7 +47,7 @@ class YourWorkflow: ) ``` -### Define Workflow parameters {#workflow-parameters} +### Define Workflow parameters {/* #workflow-parameters */} **How to define Workflow parameters using the Temporal Python SDK.** @@ -77,7 +77,7 @@ class YourParams: name: str ``` -### Define Workflow return parameters {#workflow-return-values} +### Define Workflow return parameters {/* #workflow-return-values */} **How to define Workflow return parameters using the Temporal Python SDK.** @@ -121,7 +121,7 @@ class YourWorkflow: ) ``` -### Customize your Workflow Type {#workflow-type} +### Customize your Workflow Type {/* #workflow-type */} **How to customize your Workflow Type using the Temporal Python SDK.** @@ -158,7 +158,7 @@ class YourWorkflow: ) ``` -### Develop Workflow logic {#workflow-logic-requirements} +### Develop Workflow logic {/* #workflow-logic-requirements */} **How to develop Workflow logic using the Temporal Python SDK.** diff --git a/docs/develop/python/workflows/cancellation.mdx b/docs/develop/python/workflows/cancellation.mdx index 9cf88e7df3..e454023062 100644 --- a/docs/develop/python/workflows/cancellation.mdx +++ b/docs/develop/python/workflows/cancellation.mdx @@ -35,7 +35,7 @@ Terminating a Workflow forcefully stops Workflow Execution. This action resemble In most cases, canceling is preferable because it allows the Workflow to finish gracefully. Terminate only if the Workflow is stuck and cannot be canceled normally. -## Cancel a Workflow Execution {#cancellation} +## Cancel a Workflow Execution {/* #cancellation */} Canceling a Workflow provides a graceful way to stop Workflow Execution. This action resembles sending a `SIGTERM` to a process. @@ -52,7 +52,7 @@ To cancel a Workflow Execution in Python, use the await client.get_workflow_handle("your_workflow_id").cancel() ``` -### Cancel an Activity from a Workflow {#cancel-activity} +### Cancel an Activity from a Workflow {/* #cancel-activity */} Canceling an Activity from within a Workflow requires that the Activity Execution sends Heartbeats and sets a Heartbeat Timeout. If the Heartbeat is not invoked, the Activity cannot receive a cancellation request. When any non-immediate @@ -115,7 +115,7 @@ The Activity handle is a Python task. By calling `cancel()`, you're essentially ::: -## Terminate a Workflow Execution {#termination} +## Terminate a Workflow Execution {/* #termination */} Terminating a Workflow forcefully stops Workflow Execution. This action resembles killing a process. @@ -132,7 +132,7 @@ handle. await client.get_workflow_handle("your_workflow_id").terminate() ``` -## Reset a Workflow Execution {#reset} +## Reset a Workflow Execution {/* #reset */} Resetting a Workflow Execution terminates the current Workflow Execution and starts a new Workflow Execution from a point you specify in its Event History. Use reset when a Workflow is blocked due to a non-deterministic error or other diff --git a/docs/develop/python/workflows/child-workflows.mdx b/docs/develop/python/workflows/child-workflows.mdx index af63255fdf..9e49d03b6f 100644 --- a/docs/develop/python/workflows/child-workflows.mdx +++ b/docs/develop/python/workflows/child-workflows.mdx @@ -24,7 +24,7 @@ This page shows how to do the following: - [Start a Child Workflow Execution](#child-workflows) - [Set a Parent Close Policy](#parent-close-policy) -## Start a Child Workflow Execution {#child-workflows} +## Start a Child Workflow Execution {/* #child-workflows */} **How to start a Child Workflow Execution using the Temporal Python SDK.** @@ -74,7 +74,7 @@ class GreetingWorkflow: ) ``` -### Set a Parent Close Policy {#parent-close-policy} +### Set a Parent Close Policy {/* #parent-close-policy */} **How to set a Parent Close Policy** diff --git a/docs/develop/python/workflows/continue-as-new.mdx b/docs/develop/python/workflows/continue-as-new.mdx index bb58fc01d7..fb5057faa4 100644 --- a/docs/develop/python/workflows/continue-as-new.mdx +++ b/docs/develop/python/workflows/continue-as-new.mdx @@ -24,7 +24,7 @@ This page answers the following questions for Python developers: - [When is it right to Continue-as-New?](#when) - [How to test Continue-as-New?](#how-to-test) -## What is Continue-As-New? {#what} +## What is Continue-As-New? {/* #what */} [Continue-As-New](/workflow-execution/continue-as-new) lets a Workflow Execution close successfully and creates a new Workflow Execution. You can think of it as a checkpoint when your Workflow gets too long or approaches certain scaling limits. @@ -32,7 +32,7 @@ You can think of it as a checkpoint when your Workflow gets too long or approach The new Workflow Execution is in the same [chain](/workflow-execution#workflow-execution-chain); it keeps the same Workflow Id but gets a new Run Id and a fresh Event History. It also receives your Workflow's usual parameters. -## How to Continue-As-New using the Python SDK {#how} +## How to Continue-As-New using the Python SDK {/* #how */} First, design your Workflow parameters so that you can pass in the "current state" when you Continue-As-New into the next Workflow run. This state is typically set to `None` for the original caller of the Workflow. @@ -73,20 +73,20 @@ workflow.continue_as_new( ) ```` -### Considerations for Workflows with Message Handlers {#with-message-handlers} +### Considerations for Workflows with Message Handlers {/* #with-message-handlers */} If you use Updates or Signals, don't call Continue-as-New from the handlers. Instead, wait for your handlers to finish in your main Workflow before you run `continue_as_new`. See the [`all_handlers_finished`](message-passing#wait-for-message-handlers) example for guidance. -## When is it right to Continue-as-New using the Python SDK? {#when} +## When is it right to Continue-as-New using the Python SDK? {/* #when */} Use Continue-as-New when your Workflow might encounter degraded performance or [Event History Limits](/workflow-execution/event#event-history). Temporal tracks your Workflow's progress against these limits to let you know when you should Continue-as-New. Call `workflow.info().is_continue_as_new_suggested()` to check if it's time. -## How to test Continue-as-New using the Python SDK {#how-to-test} +## How to test Continue-as-New using the Python SDK {/* #how-to-test */} Testing Workflows that naturally Continue-as-New may be time-consuming and resource-intensive. Instead, add a test hook to check your Workflow's Continue-as-New behavior faster in automated tests. diff --git a/docs/develop/python/workflows/message-passing.mdx b/docs/develop/python/workflows/message-passing.mdx index e54ca01df6..4a6821a9fb 100644 --- a/docs/develop/python/workflows/message-passing.mdx +++ b/docs/develop/python/workflows/message-passing.mdx @@ -32,7 +32,7 @@ Temporal Clients use messages to read Workflow state and control its execution. See [Workflow message passing](/encyclopedia/workflow-message-passing) for a general overview of this topic. This page introduces these features for the Temporal Python SDK. -## Write message handlers {#writing-message-handlers} +## Write message handlers {/* #writing-message-handlers */} :::info The code that follows is part of a working message passing [sample](https://github.com/temporalio/samples-python/tree/main/message_passing/introduction). @@ -44,7 +44,7 @@ Follow these guidelines when writing your message handlers: - The parameters and return values of handlers and the main Workflow function must be [serializable](/dataconversion). - Prefer [data classes](https://docs.python.org/3/library/dataclasses.html) to multiple input parameters. Data class parameters allow you to add fields without changing the calling signature. Keep in mind that serialization and deserialization can fail with the default data converter if the new field does not have a default value. -### Query handlers {#queries} +### Query handlers {/* #queries */} A [Query](/sending-messages#sending-queries) is a synchronous operation that retrieves state from a Workflow Execution: @@ -81,7 +81,7 @@ class GreetingWorkflow: - A Query handler uses `def`, not `async def`. You can't perform async operations like executing an Activity in a Query handler. -### Signal handlers {#signals} +### Signal handlers {/* #signals */} A [Signal](/sending-messages#sending-signals) is an asynchronous message sent to a running Workflow Execution to change its state and control its flow: @@ -110,7 +110,7 @@ class GreetingWorkflow: This allows you to use Activities, Child Workflows, durable [`asyncio.sleep`](https://docs.python.org/3/library/asyncio-task.html#asyncio.sleep) Timers, [`workflow.wait_condition`](https://python.temporal.io/temporalio.workflow.html#wait_condition) conditions, and more. See [Async handlers](#async-handlers) and [Workflow message passing](/encyclopedia/workflow-message-passing) for guidelines on safely using async Signal and Update handlers. -### Update handlers and validators {#updates} +### Update handlers and validators {/* #updates */} An [Update](/sending-messages#sending-updates) is a trackable synchronous request sent to a running Workflow Execution. It can change the Workflow state, control its flow, and return a result. @@ -161,7 +161,7 @@ class GreetingWorkflow: - Update (and Signal) handlers can be `async def`, letting them use Activities, Child Workflows, durable [`asyncio.sleep`](https://docs.python.org/3/library/asyncio-task.html#asyncio.sleep) Timers, [`workflow.wait_condition`](https://python.temporal.io/temporalio.workflow.html#wait_condition) conditions, and more. See [Async handlers](#async-handlers) and [Workflow message passing](/encyclopedia/workflow-message-passing) for safe usage guidelines. -## Send messages {#send-messages} +## Send messages {/* #send-messages */} To send Queries, Signals, or Updates, you call methods on a [WorkflowHandle](https://python.temporal.io/temporalio.client.WorkflowHandle.html) object: @@ -188,7 +188,7 @@ To check the argument types required when sending messages -- and the return typ ::: -### Send a Query {#send-query} +### Send a Query {/* #send-query */} Use [`WorkflowHandle.query`](https://python.temporal.io/temporalio.client.WorkflowHandle.html#query) to send a Query to a Workflow Execution: @@ -206,12 +206,12 @@ supported_languages = await workflow_handle.query( - A Worker must be online and polling the Task Queue to process a Query. -### Send a Signal {#send-signal} +### Send a Signal {/* #send-signal */} You can send a Signal to a Workflow Execution from a Temporal Client or from another Workflow Execution. However, you can only send Signals to Workflow Executions that haven’t closed. -#### Send a Signal from a Client {#send-signal-from-client} +#### Send a Signal from a Client {/* #send-signal-from-client */} Use [`WorkflowHandle.signal`](https://python.temporal.io/temporalio.client.WorkflowHandle.html#signal) to send a Signal: @@ -223,7 +223,7 @@ await workflow_handle.signal(GreetingWorkflow.approve, ApproveInput(name="me")) - The [WorkflowExecutionSignaled](/references/events#workflowexecutionsignaled) Event appears in the Workflow's Event History. -#### Send a Signal from a Workflow {#send-signal-from-workflow} +#### Send a Signal from a Workflow {/* #send-signal-from-workflow */} A Workflow can send a Signal to another Workflow, known as an _External Signal_. You'll need a Workflow handle for the external Workflow. @@ -246,7 +246,7 @@ When an External Signal is sent: - A [SignalExternalWorkflowExecutionInitiated](/references/events#signalexternalworkflowexecutioninitiated) Event appears in the sender's Event History. - A [WorkflowExecutionSignaled](/references/events#workflowexecutionsignaled) Event appears in the recipient's Event History. -#### Signal-With-Start {#signal-with-start} +#### Signal-With-Start {/* #signal-with-start */} Signal-With-Start allows a Client to send a Signal to a Workflow Execution, starting the Execution if it is not already running. To use Signal-With-Start, call the [`start_workflow`](https://python.temporal.io/temporalio.client.Client.html#start_workflow) method and pass the `start_signal` argument with the name of your Signal: @@ -267,7 +267,7 @@ async def main(): ) ``` -### Send an Update {#send-update-from-client} +### Send an Update {/* #send-update-from-client */} An Update is a synchronous, blocking call that can change Workflow state, control its flow, and return a result. @@ -316,7 +316,7 @@ To obtain an Update handle, you can: - Use [`start_update`](https://python.temporal.io/temporalio.client.WorkflowHandle.html#start_update) to start an Update and return the handle, as shown in the preceding example. - Use [`get_update_handle_for`](https://python.temporal.io/temporalio.client.WorkflowHandle.html#get_update_handle_for) to fetch a handle for an in-progress Update using the Update ID. -#### Update-With-Start {#update-with-start} +#### Update-With-Start {/* #update-with-start */} :::tip @@ -384,7 +384,7 @@ Use these non-type safe APIs: ::: -## Message handler patterns {#message-handler-patterns} +## Message handler patterns {/* #message-handler-patterns */} This section covers common write operations, such as Signal and Update handlers. It doesn't apply to pure read operations, like Queries or Update Validators. @@ -395,7 +395,7 @@ For additional information, see [Inject work into the main Workflow](/handling-m ::: -### Use async handlers {#async-handlers} +### Use async handlers {/* #async-handlers */} Signal and Update handlers can be `async def` as well as `def`. Using `async def` allows you to use `await` with Activities, Child Workflows, [`asyncio.sleep`](https://docs.python.org/3/library/asyncio-task.html#asyncio.sleep) Timers, [`workflow.wait_condition`](https://python.temporal.io/temporalio.workflow.html#wait_condition) conditions, etc. @@ -490,7 +490,7 @@ class GreetingWorkflow: return self.greetings[self.language] ``` -#### Use wait conditions in handlers {#wait-in-message-handler} +#### Use wait conditions in handlers {/* #wait-in-message-handler */} It's common to use a Workflow wait condition to wait until a handler should start. You can also use wait conditions anywhere else in the handler to wait for a specific condition to become `True`. @@ -510,7 +510,7 @@ async def my_update(self, update_input: UpdateInput) -> str: You can also use wait conditions anywhere else in the handler to wait for a specific condition to become true. This allows you to write handlers that pause at multiple points, each time waiting for a required condition to become true. -#### Ensure your handlers finish before the Workflow completes {#wait-for-message-handlers} +#### Ensure your handlers finish before the Workflow completes {/* #wait-for-message-handlers */} Workflow wait conditions can ensure your handler completes before a Workflow finishes. When your Workflow uses `async def` Signal or Update handlers, your main Workflow method can return or continue-as-new while a handler is still waiting on an async task, such as an Activity result. @@ -580,7 +580,7 @@ class WorkflowRunSeesWorkflowInitWorkflow: return is_valid ``` -### Use `asyncio.Lock` to prevent concurrent handler execution {#control-handler-concurrency} +### Use `asyncio.Lock` to prevent concurrent handler execution {/* #control-handler-concurrency */} Concurrent processes can interact in unpredictable ways. Incorrectly written [concurrent message-passing](/handling-messages#message-handler-concurrency) code may not work correctly when multiple handler instances run simultaneously. @@ -626,7 +626,7 @@ class MyWorkflow: self.y = data.y ``` -## Message handler troubleshooting {#message-handler-troubleshooting} +## Message handler troubleshooting {/* #message-handler-troubleshooting */} When sending a Signal, Update, or Query to a Workflow, your Client might encounter the following errors: @@ -638,13 +638,13 @@ When sending a Signal, Update, or Query to a Workflow, your Client might encount See [Exceptions in message handlers](/handling-messages#exceptions) for a non–Python-specific discussion of this topic. -### Problems when sending a Signal {#signal-problems} +### Problems when sending a Signal {/* #signal-problems */} When using Signal, the only exceptions that will result from your requests during its execution are the `RPCError`s described above. For Queries and Updates, the Client waits for a response from the Worker, and therefore additional errors may occur during the handler Execution by the Worker. -### Problems when sending an Update {#update-problems} +### Problems when sending an Update {/* #update-problems */} When working with Updates, in addition to the `RPCError`s described above, you may encounter these errors: @@ -683,7 +683,7 @@ When working with Updates, in addition to the `RPCError`s described above, you m - The Workflow completed normally or continued-as-new and the Workflow author did not [wait for handlers to be finished](/handling-messages#finishing-message-handlers). -### Problems when sending a Query {#query-problems} +### Problems when sending a Query {/* #query-problems */} When working with Queries, in addition to the `RPCError`s described above, you may encounter these errors: @@ -698,7 +698,7 @@ When working with Queries, in addition to the `RPCError`s described above, you m - **The handler caused the Workflow Task to fail.** This would happen, for example, if the Query handler blocks the thread for too long without yielding. -## Dynamic components {#dynamic-handler} +## Dynamic components {/* #dynamic-handler */} A dynamic Workflow, Activity, Signal, Update, or Query is a kind of unnamed item. Normally, these items are registered by name with the Worker and invoked at runtime. @@ -719,7 +719,7 @@ Reserve dynamic invocation use for cases where a name is not or can't be known a ::: -### Set a dynamic Signal, Query, or Update handler {#set-a-dynamic-signal} +### Set a dynamic Signal, Query, or Update handler {/* #set-a-dynamic-signal */} A dynamic Signal, Query, or Update refers to a special stand-in handler. It's used when an unregistered handler request arrives. @@ -754,7 +754,7 @@ This sample creates a `dynamic_signal` Signal. When an unregistered or unrecognized Signal arrives with a matching signature, dynamic assignment uses this handler to manage the Signal. It is responsible for transforming the sequence contents into usable data in a form that the method's logic can process and act on. -### Set a dynamic Workflow {#set-a-dynamic-workflow} +### Set a dynamic Workflow {/* #set-a-dynamic-workflow */} A dynamic Workflow refers to a special stand-in Workflow Definition. It's used when an unknown Workflow Execution request arrives. @@ -790,7 +790,7 @@ class DynamicWorkflow: This Workflow converts the first `Sequence` element to a string, and uses that to execute an Activity. -### Set a dynamic Activity {#set-a-dynamic-activity} +### Set a dynamic Activity {/* #set-a-dynamic-activity */} A dynamic Activity is a stand-in implementation. It's used when an Activity Task with an unknown Activity type is received by the Worker. diff --git a/docs/develop/python/workflows/schedules.mdx b/docs/develop/python/workflows/schedules.mdx index 9d32a43932..1caaa1214e 100644 --- a/docs/develop/python/workflows/schedules.mdx +++ b/docs/develop/python/workflows/schedules.mdx @@ -38,7 +38,7 @@ This page shows how to do the following: - [Temporal Cron Jobs](#temporal-cron-jobs) - [Start Delay](#start-delay) -## Schedule a Workflow {#schedule-a-workflow} +## Schedule a Workflow {/* #schedule-a-workflow */} **How to Schedule a Workflow Execution** @@ -46,7 +46,7 @@ Scheduling Workflows is a crucial aspect of any automation process, especially w Use any of the following actions to help Schedule a Workflow Execution and take control over your automation process. -### Create a Scheduled Workflow {#create} +### Create a Scheduled Workflow {/* #create */} **How to create a Scheduled Workflow** @@ -95,7 +95,7 @@ The Temporal Service doesn't guarantee when this removal will happen. ::: -### Backfill a Scheduled Workflow {#backfill} +### Backfill a Scheduled Workflow {/* #backfill */} **How to backfill a Scheduled Workflow** @@ -136,7 +136,7 @@ async def main(): ) ``` -### Delete a Scheduled Workflow {#delete} +### Delete a Scheduled Workflow {/* #delete */} **How to delete a Scheduled Workflow** @@ -161,7 +161,7 @@ async def main(): await handle.delete() ``` -### Describe a Scheduled Workflow {#describe} +### Describe a Scheduled Workflow {/* #describe */} **How to describe a Scheduled Workflow** @@ -190,7 +190,7 @@ async def main(): print(f"Returns the note: {desc.schedule.state.note}") ``` -### List a Scheduled Workflow {#list} +### List a Scheduled Workflow {/* #list */} **How to list a Scheduled Workflow** @@ -214,7 +214,7 @@ async def main() -> None: print(f"List Schedule Info: {schedule.info}.") ``` -### Pause a Scheduled Workflow {#pause} +### Pause a Scheduled Workflow {/* #pause */} **How to pause a Scheduled Workflow** @@ -241,7 +241,7 @@ async def main(): await handle.pause(note="Pausing the schedule for now") ``` -### Trigger a Scheduled Workflow {#trigger} +### Trigger a Scheduled Workflow {/* #trigger */} **How to trigger a Scheduled Workflow** @@ -267,7 +267,7 @@ async def main(): await handle.trigger() ``` -### Update a Scheduled Workflow {#update} +### Update a Scheduled Workflow {/* #update */} **How to update a Scheduled Workflow** @@ -294,7 +294,7 @@ The following example updates the Schedule to use a new argument. return ScheduleUpdate(schedule=input.description.schedule) ``` -## Temporal Cron Jobs {#temporal-cron-jobs} +## Temporal Cron Jobs {/* #temporal-cron-jobs */} **How to use Temporal Cron Jobs** @@ -341,7 +341,7 @@ Temporal Workflow Schedule Cron strings follow this format: * * * * * ``` -## Start Delay {#start-delay} +## Start Delay {/* #start-delay */} **How to use Start Delay** diff --git a/docs/develop/python/workflows/timeouts.mdx b/docs/develop/python/workflows/timeouts.mdx index 180c8adc4b..110f8b0d3d 100644 --- a/docs/develop/python/workflows/timeouts.mdx +++ b/docs/develop/python/workflows/timeouts.mdx @@ -17,7 +17,7 @@ tags: - Temporal SDKs --- -## Workflow timeouts {#workflow-timeouts} +## Workflow timeouts {/* #workflow-timeouts */} Each Workflow timeout controls the maximum duration of a different aspect of a Workflow Execution. @@ -60,7 +60,7 @@ Available timeouts are: ) ``` -## Workflow retries {#workflow-retries} +## Workflow retries {/* #workflow-retries */} **How to set a Workflow Retry Policy using the Temporal Python SDK** diff --git a/docs/develop/python/workflows/versioning.mdx b/docs/develop/python/workflows/versioning.mdx index 099bd572ea..7e9781e165 100644 --- a/docs/develop/python/workflows/versioning.mdx +++ b/docs/develop/python/workflows/versioning.mdx @@ -48,7 +48,7 @@ Support for the experimental Worker Versioning method before 2025 will be remove Temporal's [Worker Versioning](/production-deployment/worker-deployments/worker-versioning) feature allows you to tag your Workers and programmatically roll them out in Deployment Versions, so that old Workers can run old code paths and new Workers can run new code paths. This way, you can pin your Workflows to specific revisions, avoiding the need for patching. -## Versioning with Patching {#patching} +## Versioning with Patching {/* #patching */} ### Adding a patch @@ -120,7 +120,7 @@ Patching is a three-step process: 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 {#using-patched-for-workflow-history-markers} +### Patching in new code {/* #using-patched-for-workflow-history-markers */} Using `patched` inserts a marker into the Event History. During Replay, if a Worker encounters a history with that marker, it will fail the Workflow task when the Workflow code doesn't produce the same patch marker (in this case, `my-patch`). @@ -151,7 +151,7 @@ class MyWorkflow: ) ``` -### Deprecating patches {#deprecated-patches} +### Deprecating patches {/* #deprecated-patches */} After ensuring that all Workflows started with `pre_patch_activity` code have left retention, you can [deprecate the patch](https://python.temporal.io/temporalio.workflow.html#deprecate_patch). @@ -179,7 +179,7 @@ class MyWorkflow: ) ``` -### Removing a patch {#deploy-new-code} +### Removing a patch {/* #deploy-new-code */} Once your pre-patch Workflows have left retention, you can then safely deploy Workers that no longer use either the `patched()` or `deprecate_patch()` calls: diff --git a/docs/develop/python/workflows/worker-versioning-legacy.mdx b/docs/develop/python/workflows/worker-versioning-legacy.mdx index 4c278345fe..d7fee98937 100644 --- a/docs/develop/python/workflows/worker-versioning-legacy.mdx +++ b/docs/develop/python/workflows/worker-versioning-legacy.mdx @@ -12,7 +12,7 @@ tags: - Python SDK --- -## (Deprecated) How to use Worker Versioning in Python {#worker-versioning} +## (Deprecated) How to use Worker Versioning in Python {/* #worker-versioning */} :::caution diff --git a/docs/develop/python/workflows/workflow-streams.mdx b/docs/develop/python/workflows/workflow-streams.mdx index cd3225578a..eabccd27ed 100644 --- a/docs/develop/python/workflows/workflow-streams.mdx +++ b/docs/develop/python/workflows/workflow-streams.mdx @@ -250,7 +250,7 @@ A single iterator over multiple topics also avoids the cancellation race that tw Omitting `result_type` entirely or passing `result_type=None` decodes each item with the converter's default rules. For the stock JSON converter, that means a Python primitive, `dict`, or `list`. This works for fully homogeneous streams, but not for the dispatch-by-topic pattern above, where each topic has its own concrete dataclass. -### Closing the stream {#closing-the-stream} +### Closing the stream {/* #closing-the-stream */} A subscriber's `async for` does not know when the publisher is done. End-of-stream is an application-level concern; Workflow Streams does not impose a marker. Without coordination, a subscriber will keep polling until the Workflow reaches a terminal state, and a Workflow that returns immediately after its last publish can lose that publish's poll round-trip in the gap. @@ -296,7 +296,7 @@ The timeout is still required because the subscriber may not be attached, or may **Inspecting terminal status.** `subscribe()` exits cleanly when the Workflow reaches `COMPLETED`, `FAILED`, `CANCELED`, `TERMINATED`, or `TIMED_OUT`, but does not distinguish among them. If your application needs to know which (to display success or failure to the user, log the outcome, or decide whether to retry), call `await temporal_client.get_workflow_handle(workflow_id).describe()` after the loop returns to inspect the Workflow's status. -## Continue-As-New {#continue-as-new} +## Continue-As-New {/* #continue-as-new */} If your Workflow runs for minutes and finishes (a single chat completion, an order pipeline, a one-shot agent), you can skip this section. Continue-As-New becomes relevant for streams that run for hours or accumulate thousands of events, where you need to roll the run over to keep history bounded. @@ -432,7 +432,7 @@ A few details worth knowing about, mostly relevant if you're writing custom mess - **Custom handlers reading stream state on the first activation.** `WorkflowStream` registers its publish-Signal handler dynamically from `__init__`, so on the very first activation a publish Signal can be queued before class-level `@workflow.signal` or `@workflow.update` handlers have run. A handler that observes state set by stream initialization in that same activation can see pre-publish state. The fix is to make the handler `async def` and `await` once before reading state. `asyncio.sleep(0)` is a no-op yield that suffices and adds no history events. (Don't substitute `workflow.sleep(0)`, which records a timer event.) Once the first activation completes, the handler is permanent and the race does not recur. - **Type bindings aren't shared across publishers.** Each `WorkflowStream` and each `WorkflowStreamClient` records topic types only for its own instance. If two publishers bind the same topic name to different types, the mismatch is not caught at publish, and the subscriber gets a decode error when it processes events from the mismatched publisher. -## Application: Stream LLM output {#stream-llm-output} +## Application: Stream LLM output {/* #stream-llm-output */} The headline use case fits the publish/subscribe shapes documented above. An Activity calls the model and publishes deltas as they arrive; the Workflow kicks off the Activity and waits for the consumer to acknowledge end-of-stream; the consumer subscribes, accumulates the deltas, and clears its accumulated state on `RETRY` before continuing. The shape works for a terminal client, a desktop UI, or a Server-Sent Events (SSE) endpoint forwarding to a browser; whatever holds the displayed state calls `render()` to display it. diff --git a/docs/develop/ruby/activities/asynchronous-activity.mdx b/docs/develop/ruby/activities/asynchronous-activity.mdx index c574f3da5b..e9fcb66d9d 100644 --- a/docs/develop/ruby/activities/asynchronous-activity.mdx +++ b/docs/develop/ruby/activities/asynchronous-activity.mdx @@ -25,7 +25,7 @@ tags: - Temporal SDKs --- -## How to asynchronously complete an Activity {#asynchronous-activity-completion} +## How to asynchronously complete an Activity {/* #asynchronous-activity-completion */} This page describes how to asynchronously complete an Activity. diff --git a/docs/develop/ruby/activities/basics.mdx b/docs/develop/ruby/activities/basics.mdx index d441fbe1cd..2b0a26ea9b 100644 --- a/docs/develop/ruby/activities/basics.mdx +++ b/docs/develop/ruby/activities/basics.mdx @@ -11,7 +11,7 @@ tags: - Temporal SDKs --- -## Develop an Activity {#develop-activity} +## Develop an Activity {/* #develop-activity */} One of the primary things that Workflows do is orchestrate the execution of Activities. An Activity is a normal method execution that's intended to execute a single, well-defined action (either short or long-running), such as querying a database, calling a third-party API, or transcoding a media file. @@ -45,7 +45,7 @@ This is so that you can change what data is passed to the Activity without break The `execute` method in your Activity can technically accept multiple parameters of any data type that Temporal can convert. However, Temporal strongly encourages using a single parameter object to simplify versioning and maintainability. -### Activity Concurrency and Executors {#activity-concurrency-and-executors} +### Activity Concurrency and Executors {/* #activity-concurrency-and-executors */} :::note diff --git a/docs/develop/ruby/activities/dynamic-activity.mdx b/docs/develop/ruby/activities/dynamic-activity.mdx index 883e750a1e..1044ae8ef9 100644 --- a/docs/develop/ruby/activities/dynamic-activity.mdx +++ b/docs/develop/ruby/activities/dynamic-activity.mdx @@ -11,7 +11,7 @@ tags: - Temporal SDKs --- -## Set a Dynamic Activity {#set-a-dynamic-activity} +## Set a Dynamic Activity {/* #set-a-dynamic-activity */} A Dynamic Activity in Temporal is an Activity that is invoked dynamically at runtime if no other Activity with the same name is registered. An Activity can be made dynamic by invoking `activity_dynamic` class method at the top of the definition. diff --git a/docs/develop/ruby/activities/execution.mdx b/docs/develop/ruby/activities/execution.mdx index 1e5109fa3b..47fb8d88b4 100644 --- a/docs/develop/ruby/activities/execution.mdx +++ b/docs/develop/ruby/activities/execution.mdx @@ -11,7 +11,7 @@ tags: - Activity --- -## Start Activity Execution {#activity-execution} +## Start Activity Execution {/* #activity-execution */} 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. diff --git a/docs/develop/ruby/activities/timeouts.mdx b/docs/develop/ruby/activities/timeouts.mdx index c617cf45ed..51fb0712ef 100644 --- a/docs/develop/ruby/activities/timeouts.mdx +++ b/docs/develop/ruby/activities/timeouts.mdx @@ -17,7 +17,7 @@ tags: - Temporal SDKs --- -## Activity timeouts {#activity-timeouts} +## Activity timeouts {/* #activity-timeouts */} Each Activity Timeout controls a different aspect of how long an Activity Execution can take: @@ -35,7 +35,7 @@ Temporalio::Workflow.execute_activity( ) ``` -### Activity Retry Policy {#activity-retries} +### Activity Retry Policy {/* #activity-retries */} By default, Activities use a system Retry Policy. You can override it by specifying a custom Retry Policy. @@ -51,7 +51,7 @@ Temporalio::Workflow.execute_activity( ) ``` -### Override the retry interval with `next_retry_delay` {#next-retry-delay} +### Override the retry interval with `next_retry_delay` {/* #next-retry-delay */} If you raise an application-level error, you can override the Retry Policy's delay by specifying a new delay. @@ -63,7 +63,7 @@ raise Temporalio::Error::ApplicationError.new( ) ``` -## Heartbeat an Activity {#activity-heartbeats} +## Heartbeat an Activity {/* #activity-heartbeats */} A Heartbeat is a periodic signal from the Worker to the Temporal Service indicating the Activity is still alive and making progress. @@ -86,7 +86,7 @@ class MyActivity < Temporalio::Activity::Definition end ``` -### Heartbeat Timeout {#heartbeat-timeout} +### Heartbeat Timeout {/* #heartbeat-timeout */} The Heartbeat Timeout sets the maximum duration between Heartbeats before the Temporal Service considers the Activity failed. diff --git a/docs/develop/ruby/best-practices/converters-and-encryption.mdx b/docs/develop/ruby/best-practices/converters-and-encryption.mdx index 21a0cdd95b..b82754f932 100644 --- a/docs/develop/ruby/best-practices/converters-and-encryption.mdx +++ b/docs/develop/ruby/best-practices/converters-and-encryption.mdx @@ -32,7 +32,7 @@ The server itself never adds encryption over Payloads. Therefore, unless client-side encryption is implemented, Payload data will be persisted in non-encrypted form to the data store, and any Client that can make requests to a Temporal namespace (including the Temporal UI and CLI) will be able to read Payloads contained in Workflows. When working with sensitive data, you should always implement Payload encryption. -## Custom Payload Codec {#custom-payload-codec} +## Custom Payload Codec {/* #custom-payload-codec */} Custom Data Converters can change the default Temporal Data Conversion behavior by adding hooks, sending payloads to external storage, or performing different encoding steps. If you only need to change the encoding performed on your payloads -- by adding compression or encryption -- you can override the default Data Converter to use a new `PayloadCodec`. @@ -94,11 +94,11 @@ You create, operate, and manage access to your Codec Server in your own environm The Temporal CLI and the Web UI in turn provide built-in hooks to call the Codec Server to decode encrypted payloads on demand. Refer to the [Codec Server](/production-deployment/data-encryption) documentation for information on how to design and deploy a Codec Server. -## Payload conversion {#custom-payload-converter} +## Payload conversion {/* #custom-payload-converter */} Temporal SDKs provide a default [Payload Converter](/payload-converter) that can be customized to convert a custom data type to [Payload](/dataconversion#payload) and back. -### Conversion sequence {#conversion-sequence} +### Conversion sequence {/* #conversion-sequence */} The order in which your encoding Payload Converters are applied depend on the order given to the Data Converter. You can set multiple encoding Payload Converters to run your conversions. @@ -112,7 +112,7 @@ Temporal's Converter architecture looks like this: title="Temporal converter architecture" /> -### Supported Data Types {#supported-data-types} +### Supported Data Types {/* #supported-data-types */} Data converters are used to convert raw Temporal payloads to/from actual Ruby types. A custom data converter can be set via the `data_converter` keyword argument when creating a client. Data converters are a combination of payload converters, payload codecs, and failure converters. @@ -142,7 +142,7 @@ Also many Ruby ORMs do many lazy things and therefore provide unclear serializat Instead, consider having models specific for workflows/activities and translate to/from existing models as needed. See the next section on how to do this with ActiveModel objects. -#### ActiveModel {#active-model} +#### ActiveModel {/* #active-model */} By default, ActiveModel objects do not natively support the `JSON` module. A mixin can be created to add this support for ActiveModel, for example: diff --git a/docs/develop/ruby/best-practices/debugging.mdx b/docs/develop/ruby/best-practices/debugging.mdx index 67264d7636..5df793af92 100644 --- a/docs/develop/ruby/best-practices/debugging.mdx +++ b/docs/develop/ruby/best-practices/debugging.mdx @@ -15,21 +15,21 @@ tags: - Errors --- -## Debugging {#debug} +## Debugging {/* #debug */} This page shows how to do the following: - [Debug in a development environment](#debug-in-a-development-environment) - [Debug in a production environment](#debug-in-a-production-environment) -## Debug in a development environment {#debug-in-a-development-environment} +## Debug in a development environment {/* #debug-in-a-development-environment */} In developing Workflows, you can use the normal development tools of logging and a debugger to see what’s happening in your Workflow. 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 production environment {#debug-in-a-production-environment} +## Debug in a production environment {/* #debug-in-a-production-environment */} For production Workflows, debugging options include: diff --git a/docs/develop/ruby/best-practices/error-handling.mdx b/docs/develop/ruby/best-practices/error-handling.mdx index 8d9d23d4c9..d4ef624f8c 100644 --- a/docs/develop/ruby/best-practices/error-handling.mdx +++ b/docs/develop/ruby/best-practices/error-handling.mdx @@ -19,7 +19,7 @@ tags: - Errors --- -## Raise and Handle Exceptions {#exception-handling} +## Raise and Handle Exceptions {/* #exception-handling */} In each Temporal SDK, error handling is implemented idiomatically, following the conventions of the language. Temporal uses several different error classes internally — for example, [`CancelledError`](https://ruby.temporal.io/Temporalio/Error/CanceledError.html) in the Ruby SDK, to handle a Workflow cancellation. @@ -74,7 +74,7 @@ end You can alternately specify a list of errors that are non-retryable in your Activity [Retry Policy](/develop/ruby/activities/timeouts#activity-retries). -## Failing Workflows {#workflow-failure} +## Failing Workflows {/* #workflow-failure */} One of the core design principles of Temporal is that an Activity Failure will never directly cause a Workflow Failure — a Workflow should never return as Failed unless deliberately. The default retry policy associated with Temporal Activities is to retry them until reaching a certain timeout threshold. diff --git a/docs/develop/ruby/best-practices/testing-suite.mdx b/docs/develop/ruby/best-practices/testing-suite.mdx index 2fd2795754..1ac7c51738 100644 --- a/docs/develop/ruby/best-practices/testing-suite.mdx +++ b/docs/develop/ruby/best-practices/testing-suite.mdx @@ -26,7 +26,7 @@ This page shows how to do the following: The Ruby test-suite feature guide describes the frameworks that facilitate Workflow and integration testing. -## Types of Tests {#types-of-tests} +## Types of Tests {/* #types-of-tests */} In the context of Temporal, you can create these types of automated tests: @@ -41,14 +41,14 @@ We generally recommend writing the majority of your tests as integration tests. Because the test server supports skipping time, use the test server for both end-to-end and integration tests with Workers. -## Test frameworks {#test-frameworks} +## Test frameworks {/* #test-frameworks */} **Compatible testing frameworks** The Ruby SDK is compatible with any testing framework and does not have a specific recommendation. Most Ruby SDK samples use [minitest](https://github.com/minitest/minitest). -## Testing Workflows {#testing-workflows} +## Testing Workflows {/* #testing-workflows */} Workflow testing can be done in an integration-test fashion against a real server, however it is hard to simulate timeouts and other long time-based code. Using the time-skipping Workflow test environment can help there. @@ -225,13 +225,13 @@ When testing Workflows, often you don't want to actually run the Activities. Activities are just classes that extend `Temporalio::Activity::Definition`. Simply write different/empty/fake/asserting ones and pass those to the Worker to have different activities called during the test. -## Testing Activities {#test-activities} +## Testing Activities {/* #test-activities */} Unit testing an Activity or any code that could run in an Activity is done via the `Temporalio::Testing::ActivityEnvironment` class. Simply instantiate the class, and any code inside the block to `run` will be invoked inside the activity context. Several things about the activity environment can be customized via parameters when constructing the environment including setting the info, providing a proc to call back on each heartbeat, setting the cancellation to be used, etc. -## Replay test {#replay-test} +## Replay test {/* #replay-test */} Given a Workflow's history, it can be replayed locally to check for things like non-determinism errors. For example, assuming the `history_json` parameter below is given a JSON string of history exported from the CLI or web UI for workflow `MyWorkflow`, the following method will replay it: diff --git a/docs/develop/ruby/client/temporal-client.mdx b/docs/develop/ruby/client/temporal-client.mdx index 46b7f6ea4e..24c5e1acfe 100644 --- a/docs/develop/ruby/client/temporal-client.mdx +++ b/docs/develop/ruby/client/temporal-client.mdx @@ -30,7 +30,7 @@ This page shows you how to do the following using the Ruby SDK with the Temporal A Temporal Client cannot be initialized and used inside a Workflow. However, it is acceptable and common to use a Temporal Client inside an Activity to communicate with a Temporal Service. -## Connect to development Temporal Service {#connect-to-development-service} +## Connect to development Temporal Service {/* #connect-to-development-service */} Use [`Client.connect`](https://ruby.temporal.io/Temporalio/Client.html#connect-class_method) to create a client. Connection options include the Temporal Server address, Namespace, and (optionally) TLS configuration. You can provide @@ -211,7 +211,7 @@ client = Temporalio::Client.connect('localhost:7233', 'default') -## Connect to Temporal Cloud {#connect-to-temporal-cloud} +## Connect to Temporal Cloud {/* #connect-to-temporal-cloud */} You can connect to Temporal Cloud using either an [API key](/cloud/api-keys) or through mTLS. Connection to Temporal Cloud or any secured Temporal Service requires additional connection options compared to connecting to an unsecured @@ -418,7 +418,7 @@ For more information about configuring TLS to secure inter- and intra-network co -## Start a Workflow {#start-workflow} +## Start a Workflow {/* #start-workflow */} To start a Workflow Execution, supply: @@ -439,7 +439,7 @@ result = my_client.execute_workflow( puts "Result: #{result}" ``` -## Get Workflow results {#get-workflow-results} +## Get Workflow results {/* #get-workflow-results */} Once a Workflow Execution is started, the Workflow Id and Run Id can be used to uniquely identify it. diff --git a/docs/develop/ruby/platform/observability.mdx b/docs/develop/ruby/platform/observability.mdx index fa3cf42edd..f28ec24946 100644 --- a/docs/develop/ruby/platform/observability.mdx +++ b/docs/develop/ruby/platform/observability.mdx @@ -29,7 +29,7 @@ This page covers capabilities related to viewing the state of the application, i The observability guide covers the many ways to view the current state of your [Temporal Application](/temporal#temporal-application). This includes viewing [Workflow Executions](/workflow-execution) tracked by the [Temporal Platform](/temporal#temporal-platform), as well as inspecting state at any point during execution. -## Emit metrics {#metrics} +## Emit metrics {/* #metrics */} Each Temporal SDK can optionally emit metrics from either the Client or Worker process. Metrics can be scraped by systems like Prometheus, and graphs can be created using tools like Grafana. @@ -60,7 +60,7 @@ Temporalio::Runtime.default = Temporalio::Runtime.new( Instead of Prometheus or OpenTelemetry, an instance of `Temporalio::Runtime::MetricBuffer` can be provided as a `buffer` argument to the `MetricsOptions`. `retrieve_updates` can then be periodically called on the buffer to get metric updates. -## Setup Tracing {#tracing} +## Setup Tracing {/* #tracing */} Tracing enables observability into the sequence of calls across your application, including Workflows and Activities. @@ -84,7 +84,7 @@ my_client = Temporalio::Client.connect( When your Client is connected, spans are created for all Client calls, Activities, and Workflow invocations on the Worker. Spans are created and serialized through the server to give one trace for a Workflow Execution. -## Log from a Workflow {#logging} +## Log from a Workflow {/* #logging */} Logging enables you to capture and persist important execution details from your Workflow and Activity code. @@ -124,11 +124,11 @@ There's also one for use in activities that appends Activity details to every lo Temporalio::Activity::Context.current.logger.info("Some log #{some_value}") ``` -## Use Visibility APIs {#visibility} +## Use Visibility APIs {/* #visibility */} Visibility refers to Temporal features for listing, filtering, and inspecting Workflow Executions. -### Use Search Attributes {#search-attributes} +### Use Search Attributes {/* #search-attributes */} - [Default Search Attributes](/search-attribute#default-search-attribute) like `WorkflowType`, `StartTime`, and `ExecutionStatus` are automatically indexed. - [Custom Search Attributes](/search-attribute#custom-search-attribute) let you store domain-specific metadata for Workflows. @@ -158,7 +158,7 @@ The steps to using custom Search Attributes are: - [In the Temporal CLI](/cli/operator#list-2) - In code by calling `list_workflows`. -### List Workflow Executions {#list-workflow-executions} +### List Workflow Executions {/* #list-workflow-executions */} Use the [list_workflows](https://ruby.temporal.io/Temporalio/Client.html#list_workflows-instance_method) method on the Client and pass a [List Filter](/list-filter) as an argument to filter the listed Workflows. The result is a lazy enumerator/enumerable. @@ -169,7 +169,7 @@ my_client.list_workflows("WorkflowType='GreetingWorkflow'").each do |wf| end ``` -### Set Custom Search Attributes {#custom-search-attributes} +### Set Custom Search Attributes {/* #custom-search-attributes */} After you've created custom Search Attributes in your Temporal Service (using `temporal operator search-attribute create`or the Cloud UI), you can set the values of the custom Search Attributes when starting a Workflow. @@ -193,7 +193,7 @@ handle = my_client.start_workflow( ) ``` -### Upsert Search Attributes {#upsert-search-attributes} +### Upsert Search Attributes {/* #upsert-search-attributes */} You can upsert Search Attributes to add, update, or remove Search Attributes from within Workflow code. diff --git a/docs/develop/ruby/workers/run-worker-process.mdx b/docs/develop/ruby/workers/run-worker-process.mdx index a218719807..19f01c1a04 100644 --- a/docs/develop/ruby/workers/run-worker-process.mdx +++ b/docs/develop/ruby/workers/run-worker-process.mdx @@ -11,7 +11,7 @@ tags: - Worker --- -## Run Worker Process {#run-worker-process} +## Run Worker Process {/* #run-worker-process */} The [Worker Process](/workers#worker-process) is where Workflow Functions and Activity Functions are actually executed. In a Temporal application deployment, you ship and scale as many Workers as you need to handle the load of your Workflows and Activities. diff --git a/docs/develop/ruby/workflows/basics.mdx b/docs/develop/ruby/workflows/basics.mdx index b535b79e1f..16b1a7a106 100644 --- a/docs/develop/ruby/workflows/basics.mdx +++ b/docs/develop/ruby/workflows/basics.mdx @@ -11,7 +11,7 @@ tags: - Temporal SDKs --- -## Develop a Workflow {#develop-workflow} +## Develop a Workflow {/* #develop-workflow */} Workflows are the fundamental unit of a Temporal Application, and it all starts with the development of a [Workflow Definition](/workflow-definition). @@ -36,7 +36,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. -### Workflow Logic Requirements {#workflow-logic-requirements} +### Workflow Logic Requirements {/* #workflow-logic-requirements */} Temporal Workflows [must be deterministic](https://docs.temporal.io/workflows#deterministic-constraints), which includes Ruby workflows. This means there are several things workflows cannot do such as: @@ -52,7 +52,7 @@ To prevent illegal workflow calls, a call tracer is put on the workflow thread t calls are made. Which calls are illegal is configurable in the worker options. -### Customize Workflow Type {#workflow-type} +### Customize Workflow Type {/* #workflow-type */} Workflows have a Type that are referred to as the Workflow name. diff --git a/docs/develop/ruby/workflows/cancellation.mdx b/docs/develop/ruby/workflows/cancellation.mdx index 77c61a1bb5..7fbf6bc7a3 100644 --- a/docs/develop/ruby/workflows/cancellation.mdx +++ b/docs/develop/ruby/workflows/cancellation.mdx @@ -39,7 +39,7 @@ Terminating a Workflow forcefully stops Workflow Execution. This action resemble In most cases, canceling is preferable because it allows the Workflow to finish gracefully. Terminate only if the Workflow is stuck and cannot be canceled normally. -## Cancellation {#cancellation} +## Cancellation {/* #cancellation */} To give a Workflow and its Activities the ability to be cancelled, do the following: @@ -48,7 +48,7 @@ To give a Workflow and its Activities the ability to be cancelled, do the follow - Listen for and handle a Cancellation request within an Activity. - Send a Cancellation request from a Temporal Client. -## Handle Cancellation in Workflow {#handle-cancellation-in-workflow} +## Handle Cancellation in Workflow {/* #handle-cancellation-in-workflow */} Workflow Definitions can be written to respond to cancellation requests. It is common for an Activity to be run on Cancellation to perform cleanup. @@ -83,7 +83,7 @@ class MyWorkflow < Temporalio::Workflow::Definition end ``` -## Handle Cancellation in an Activity {#handle-cancellation-in-an-activity} +## Handle Cancellation in an Activity {/* #handle-cancellation-in-an-activity */} Ensure that the Activity is [Heartbeating](/develop/ruby/activities/timeouts#activity-heartbeats) to receive the Cancellation request and stop execution. Also make sure that the @@ -107,7 +107,7 @@ class MyActivity < Temporalio::Activity::Definition end ``` -## Request Cancellation {#request-cancellation} +## Request Cancellation {/* #request-cancellation */} Use `cancel` on the `WorkflowHandle` to cancel a Workflow Execution. @@ -158,7 +158,7 @@ class MyWorkflow < Temporalio::Workflow::Definition end ``` -## Termination {#termination} +## Termination {/* #termination */} To Terminate a Workflow Execution in Ruby, use the `terminate` method on the Workflow handle. @@ -175,7 +175,7 @@ handle.terminate Workflow Executions can also be Terminated directly from the WebUI. In this case, a custom note can be logged from the UI when that happens. -## Reset a Workflow Execution {#reset} +## Reset a Workflow Execution {/* #reset */} Resetting a Workflow Execution terminates the current Workflow Execution and starts a new Workflow Execution from a point you specify in its Event History. Use reset when a Workflow is blocked due to a non-deterministic error or other diff --git a/docs/develop/ruby/workflows/child-workflows.mdx b/docs/develop/ruby/workflows/child-workflows.mdx index 566504ebda..0064e1a5f6 100644 --- a/docs/develop/ruby/workflows/child-workflows.mdx +++ b/docs/develop/ruby/workflows/child-workflows.mdx @@ -23,7 +23,7 @@ This page shows how to do the following: - [Start a Child Workflow Execution](#child-workflows) using the Ruby SDK - [Set a Parent Close Policy](#parent-close-policy) using the Ruby SDK -## Start a Child Workflow Execution {#child-workflows} +## Start a Child Workflow Execution {/* #child-workflows */} A [Child Workflow Execution](/child-workflows) is a Workflow Execution that is scheduled from within another Workflow using a Child Workflow API. @@ -46,7 +46,7 @@ This is useful if you want to do something after it has only started, or to get Temporalio::Workflow.execute_child_workflow(MyChildWorkflow, 'my-workflow-arg') ``` -## Set a Parent Close Policy {#parent-close-policy} +## Set a Parent Close Policy {/* #parent-close-policy */} A [Parent Close Policy](/parent-close-policy) determines what happens to a Child Workflow Execution if its Parent changes to a Closed status (Completed, Failed, or Timed Out). diff --git a/docs/develop/ruby/workflows/continue-as-new.mdx b/docs/develop/ruby/workflows/continue-as-new.mdx index a570433a18..b2ec3a090e 100644 --- a/docs/develop/ruby/workflows/continue-as-new.mdx +++ b/docs/develop/ruby/workflows/continue-as-new.mdx @@ -35,7 +35,7 @@ The Continue-As-New feature enables developers to complete the current Workflow The new Workflow Execution has the same Workflow Id, but a different Run Id, and has its own Event History. -## Continue-As-New in Ruby {#continue-as-new} +## Continue-As-New in Ruby {/* #continue-as-new */} To Continue-As-New in Ruby, raise a `Temporalio::Workflow::ContinueAsNewError` from inside your Workflow, which will stop the Workflow immediately and Continue-As-New. diff --git a/docs/develop/ruby/workflows/dynamic-workflow.mdx b/docs/develop/ruby/workflows/dynamic-workflow.mdx index d778a07cd4..fa52f50860 100644 --- a/docs/develop/ruby/workflows/dynamic-workflow.mdx +++ b/docs/develop/ruby/workflows/dynamic-workflow.mdx @@ -11,7 +11,7 @@ tags: - Temporal SDKs --- -## Set a Dynamic Workflow {#set-a-dynamic-workflow} +## Set a Dynamic Workflow {/* #set-a-dynamic-workflow */} A Dynamic Workflow in Temporal is a Workflow that is invoked dynamically at runtime if no other Workflow with the same name is registered. A Workflow can be made dynamic by invoking `workflow_dynamic` class method at the top of the definition. diff --git a/docs/develop/ruby/workflows/futures.mdx b/docs/develop/ruby/workflows/futures.mdx index 2749a80317..aa8461bc7e 100644 --- a/docs/develop/ruby/workflows/futures.mdx +++ b/docs/develop/ruby/workflows/futures.mdx @@ -11,7 +11,7 @@ tags: - Temporal SDKs --- -## Workflow Futures {#workflow-futures} +## Workflow Futures {/* #workflow-futures */} `Temporalio::Workflow::Future` can be used for running things in the background or concurrently. Temporal provides Workflow-safe wrappers around some core language features in cases like these. diff --git a/docs/develop/ruby/workflows/message-passing.mdx b/docs/develop/ruby/workflows/message-passing.mdx index dacb835696..de471ed285 100644 --- a/docs/develop/ruby/workflows/message-passing.mdx +++ b/docs/develop/ruby/workflows/message-passing.mdx @@ -27,7 +27,7 @@ Clients use messages to read Workflow state or change its behavior. See [Workflow message passing](/encyclopedia/workflow-message-passing) for a general overview. -## Write message handlers {#writing-message-handlers} +## Write message handlers {/* #writing-message-handlers */} :::info The code that follows is part of a [working solution](https://github.com/temporalio/samples-ruby/tree/main/message_passing_simple). @@ -41,7 +41,7 @@ Follow these guidelines when writing your message handlers: - Prefer single hash/object input parameter to multiple input parameters. Hash/object parameters allow you to add fields without changing the calling signature. -### Query handlers {#queries} +### Query handlers {/* #queries */} A [Query](/sending-messages#sending-queries) is a synchronous operation that retrieves state from a Workflow Execution. Define as a method: @@ -84,7 +84,7 @@ end - A Query handler must not modify Workflow state. - You can't perform async blocking operations such as executing an Activity in a Query handler. -### Signal handlers {#signals} +### Signal handlers {/* #signals */} A [Signal](/sending-messages#sending-signals) is an asynchronous message sent to a running Workflow Execution to change its state and control its flow: @@ -113,7 +113,7 @@ end This allows you to use Activities, Child Workflows, durable Timers, wait conditions, and more. See [Async handlers](#async-handlers) and [Workflow message passing](/encyclopedia/workflow-message-passing) for guidelines on safely using async Signal and Update handlers. -### Update handlers and validators {#updates} +### Update handlers and validators {/* #updates */} An [Update](/sending-messages#sending-updates) is a trackable synchronous request sent to a running Workflow Execution. It can change the Workflow state, control its flow, and return a result. @@ -166,7 +166,7 @@ end This allows you to use Activities, Child Workflows, durable Timers, wait conditions, and more. See [Async handlers](#async-handlers) and [Workflow message passing](/encyclopedia/workflow-message-passing) for guidelines on safely using async Update and Signal handlers. -## Send messages {#send-messages} +## Send messages {/* #send-messages */} To send Queries, Signals, or Updates you call methods on a [`WorkflowHandle`](https://ruby.temporal.io/Temporalio/Client/WorkflowHandle.html) instance. To obtain the Workflow handle, you can: @@ -195,7 +195,7 @@ To check the argument types required when sending messages -- and the return typ ::: -### Send a Query {#send-query} +### Send a Query {/* #send-query */} Call a Query method with [`WorkflowHandle#query`](https://ruby.temporal.io/Temporalio/Client/WorkflowHandle.html#query-instance_method): @@ -211,12 +211,12 @@ supported_languages = handle.query(MessagePassingSimple::GreetingWorkflow.langua - A Worker must be online and polling the Task Queue to process a Query. -### Send a Signal {#send-signal} +### Send a Signal {/* #send-signal */} You can send a Signal to a Workflow Execution from a Temporal Client or from another Workflow Execution. However, you can only send Signals to Workflow Executions that haven’t closed. -#### From a Client {#send-signal-from-client} +#### From a Client {/* #send-signal-from-client */} Use [`WorkflowHandle#signal`](https://ruby.temporal.io/Temporalio/Client/WorkflowHandle.html#signal-instance_method) from Client code to send a Signal: @@ -228,7 +228,7 @@ handle.signal(MessagePassingSimple::GreetingWorkflow.approve, { name: 'John Q. A - The [WorkflowExecutionSignaled](/references/events#workflowexecutionsignaled) Event appears in the Workflow's Event History. -#### From a Workflow {#send-signal-from-workflow} +#### From a Workflow {/* #send-signal-from-workflow */} A Workflow can send a Signal to another Workflow, known as an _External Signal_. In this case you need to obtain a Workflow handle for the external Workflow. @@ -248,7 +248,7 @@ When an External Signal is sent: - A [SignalExternalWorkflowExecutionInitiated](/references/events#signalexternalworkflowexecutioninitiated) Event appears in the sender's Event History. - A [WorkflowExecutionSignaled](/references/events#workflowexecutionsignaled) Event appears in the recipient's Event History. -#### Signal-With-Start {#signal-with-start} +#### Signal-With-Start {/* #signal-with-start */} Signal-With-Start allows a Client to send a Signal to a Workflow Execution, starting the Execution if it is not already running. If there's a Workflow running with the given Workflow Id, it will be signaled. @@ -270,7 +270,7 @@ handle = client.signal_with_start_workflow( ) ``` -### Send an Update {#send-update-from-client} +### Send an Update {/* #send-update-from-client */} An Update is a synchronous, blocking call that can change Workflow state, control its flow, and return a result. @@ -312,7 +312,7 @@ To send an Update to a Workflow Execution, you can: For more details, see the "Async handlers" section. -#### Update-With-Start {#update-with-start} +#### Update-With-Start {/* #update-with-start */} :::tip Stability @@ -357,7 +357,7 @@ update_result = client.execute_with_start_workflow( workflow_result = start_workflow_operation.workflow_handle.result ``` -## Message handler patterns {#message-handler-patterns} +## Message handler patterns {/* #message-handler-patterns */} This section covers common write operations, such as Signal and Update handlers. It doesn't apply to pure read operations, like Queries or Update Validators. @@ -368,7 +368,7 @@ For additional information, see [Inject work into the main Workflow](/handling-m ::: -### Add async handlers {#async-handlers} +### Add async handlers {/* #async-handlers */} Signal and Update handlers can be asynchronous as well as blocking. Using asynchronous calls allows you to wait for Activities, Child Workflows, Durable Timers, wait conditions, etc. @@ -441,7 +441,7 @@ After updating the code for asynchronous calls, your Update handler can schedule Although an async Signal handler can initiate similar network tasks, using an Update handler allows the Client to receive a result or error once the Activity completes. This lets your Client track the progress of asynchronous work performed by the Update's Activities, Child Workflows, etc. -### Use wait conditions {#block-with-wait} +### Use wait conditions {/* #block-with-wait */} Sometimes, async Signal or Update handlers need to meet certain conditions before they should continue. Using a wait condition with [`wait_condition`](https://ruby.temporal.io/Temporalio/Workflow.html#wait_condition-class_method) sets a function that prevents the code from proceeding until the condition is truthy. @@ -455,7 +455,7 @@ Here are two important use cases for `wait_condition`: The condition state you're waiting for can be updated by and reflect any part of the Workflow code. This includes the main Workflow method, other handlers, or child coroutines spawned by the main Workflow method, and so forth. -#### In handlers {#wait-in-handlers} +#### In handlers {/* #wait-in-handlers */} Sometimes, async Signal or Update handlers need to meet certain conditions before they should continue. Using a wait condition with [`wait_condition`](https://ruby.temporal.io/Temporalio/Workflow.html#wait_condition-class_method) sets a function that prevents the code from proceeding until the condition is truthy. @@ -474,7 +474,7 @@ end Remember: Handlers can execute before the main Workflow method starts. -#### Before finishing the Workflow {#wait-for-message-handlers} +#### Before finishing the Workflow {/* #wait-for-message-handlers */} Workflow wait conditions can ensure your handler completes before a Workflow finishes. When your Workflow uses async Signal or Update handlers, your main Workflow method can return or continue-as-new while a handler is still waiting on an async task, such as an Activity result. @@ -540,7 +540,7 @@ class WorkflowInitWorkflow < Temporalio::Workflow::Definition end ``` -### Use locks to prevent concurrent handler execution {#control-handler-concurrency} +### Use locks to prevent concurrent handler execution {/* #control-handler-concurrency */} Concurrent processes can interact in unpredictable ways. Incorrectly written [concurrent message-passing](/handling-messages#message-handler-concurrency) code may not work correctly when multiple handler instances run simultaneously. @@ -595,7 +595,7 @@ end For additional concurrency options, `wait_condition` can be used to do more advanced things such as using an integer attribute + `wait_condition` as a semaphore. -## Troubleshooting {#message-handler-troubleshooting} +## Troubleshooting {/* #message-handler-troubleshooting */} When sending a Signal, Update, or Query to a Workflow, your Client might encounter the following errors: @@ -607,7 +607,7 @@ When sending a Signal, Update, or Query to a Workflow, your Client might encount See [Exceptions in message handlers](/handling-messages#exceptions) for a non–Ruby-specific discussion of this topic. -### Signal issues {#signal-problems} +### Signal issues {/* #signal-problems */} When using Signal, the only exception that will result from your requests during its execution is `RPCError`. All handlers may experience additional exceptions during the initial (pre-Worker) part of a handler request lifecycle. @@ -615,7 +615,7 @@ All handlers may experience additional exceptions during the initial (pre-Worker For Queries and Updates, the Client waits for a response from the Worker. If an issue occurs during the handler Execution by the Worker, the Client may receive an exception. -### Update issues {#update-problems} +### Update issues {/* #update-problems */} When working with Updates, you may encounter these errors: @@ -655,7 +655,7 @@ When working with Updates, you may encounter these errors: - The Workflow completed normally or continued-as-new and the Workflow author did not [wait for handlers to be finished](/handling-messages#finishing-message-handlers). -### Query issues {#query-problems} +### Query issues {/* #query-problems */} When working with Queries, you may encounter these errors: @@ -670,7 +670,7 @@ When working with Queries, you may encounter these errors: - **The handler caused the Workflow Task to fail.** This would happen, for example, if the Query handler blocks the thread for too long without yielding. -## Dynamic handlers {#dynamic-handler} +## Dynamic handlers {/* #dynamic-handler */} Temporal supports Dynamic Queries, Signals, Updates, Workflows, and Activities. These are unnamed handlers that are invoked if no other statically defined handler with the given name exists. @@ -690,7 +690,7 @@ They are meant to handle edge cases and act as a catch-all, not as the main way ::: -### Dynamic Query {#set-a-dynamic-query} +### Dynamic Query {/* #set-a-dynamic-query */} A Dynamic Query in Temporal is a Query method that is invoked dynamically at runtime if no other Query with the same name is registered. A Query can be made dynamic by setting `dynamic` to `true` on the `workflow_query` class method. @@ -709,7 +709,7 @@ def dynamic_query(query_name, *args) end ``` -### Dynamic Signal {#set-a-dynamic-signal} +### Dynamic Signal {/* #set-a-dynamic-signal */} A Dynamic Signal in Temporal is a Signal that is invoked dynamically at runtime if no other Signal with the same input is registered. A Signal can be made dynamic by setting `dynamic` to `true` on the `workflow_signal` class method. @@ -728,7 +728,7 @@ def dynamic_signal(signal_name, *args) end ``` -### Dynamic Update {#set-a-dynamic-update} +### Dynamic Update {/* #set-a-dynamic-update */} A Dynamic Update in Temporal is an Update that is invoked dynamically at runtime if no other Update with the same input is registered. An Update can be made dynamic by setting `dynamic` to `true` on the `workflow_update` class method. diff --git a/docs/develop/ruby/workflows/schedules.mdx b/docs/develop/ruby/workflows/schedules.mdx index a2fe834889..7e4f357f94 100644 --- a/docs/develop/ruby/workflows/schedules.mdx +++ b/docs/develop/ruby/workflows/schedules.mdx @@ -27,14 +27,14 @@ This page shows how to do the following: - [Update a Scheduled Workflow](#update-a-scheduled-workflow) - [Use Start Delay](#start-delay) -## Schedule a Workflow {#schedule-a-workflow} +## Schedule a Workflow {/* #schedule-a-workflow */} Scheduling Workflows is a crucial aspect of automation. By scheduling a Workflow, you can automate repetitive tasks, reduce manual intervention, and ensure timely execution. Use the following actions to manage Scheduled Workflows. -### Create a Scheduled Workflow {#create-a-workflow} +### Create a Scheduled Workflow {/* #create-a-workflow */} The create action enables you to create a new Schedule. When you create a new Schedule, a unique Schedule ID is generated, which you can use to reference the Schedule in other Schedule commands. @@ -69,7 +69,7 @@ The Temporal Service doesn't guarantee when this removal will happen. ::: -### Backfill a Scheduled Workflow {#backfill-a-scheduled-workflow} +### Backfill a Scheduled Workflow {/* #backfill-a-scheduled-workflow */} The backfill action executes Actions ahead of their specified time range. This command is useful when you need to execute a missed or delayed Action, or when you want to test the Workflow before its scheduled time. @@ -88,7 +88,7 @@ handle.backfill( ) ``` -### Delete a Scheduled Workflow {#delete-a-scheduled-workflow} +### Delete a Scheduled Workflow {/* #delete-a-scheduled-workflow */} The delete action enables you to delete a Schedule. When you delete a Schedule, it does not affect any Workflows that were started by the Schedule. @@ -99,7 +99,7 @@ handle = my_client.schedule_handle('my-schedule-id') handle.delete ``` -### Describe a Scheduled Workflow {#describe-a-scheduled-workflow} +### Describe a Scheduled Workflow {/* #describe-a-scheduled-workflow */} The describe action shows the current Schedule configuration, including information about past, current, and future Workflow Runs. This command is helpful when you want to get a detailed view of the Schedule and its associated Workflow Runs. @@ -111,7 +111,7 @@ desc = handle.describe puts "Schedule info: #{desc.info}" ``` -### List a Scheduled Workflow {#list-a-scheduled-workflow} +### List a Scheduled Workflow {/* #list-a-scheduled-workflow */} The list action lists all the available Schedules. This command is useful when you want to view a list of all the Schedules and their respective Schedule IDs. @@ -125,7 +125,7 @@ my_client.list_schedules.each do |sched| end ``` -### Pause a Scheduled Workflow {#pause-a-scheduled-workflow} +### Pause a Scheduled Workflow {/* #pause-a-scheduled-workflow */} The pause action enables you to pause and unpause a Schedule. When you pause a Schedule, all the future Workflow Runs associated with the Schedule are temporarily stopped. This command is useful when you want to temporarily halt a Workflow due to maintenance or any other reason. @@ -137,7 +137,7 @@ handle = my_client.schedule_handle('my-schedule-id') handle.pause(note: 'Pausing the schedule for now') ``` -### Trigger a Scheduled Workflow {#trigger-a-scheduled-workflow} +### Trigger a Scheduled Workflow {/* #trigger-a-scheduled-workflow */} The trigger action triggers an immediate action with a given Schedule. By default, this action is subject to the Overlap Policy of the Schedule. This command is helpful when you want to execute a Workflow outside of its scheduled time. @@ -148,7 +148,7 @@ handle = my_client.schedule_handle('my-schedule-id') handle.trigger ``` -### Update a Scheduled Workflow {#update-a-scheduled-workflow} +### Update a Scheduled Workflow {/* #update-a-scheduled-workflow */} The update action enables you to update an existing Schedule. This command is useful when you need to modify the Schedule's configuration, such as changing the start time, end time, or interval. @@ -172,7 +172,7 @@ handle.update do |input| end ``` -## Use Start Delay {#start-delay} +## Use Start Delay {/* #start-delay */} Use the `start_delay` to schedule a Workflow Execution at a specific one-time future point rather than on a recurring schedule. diff --git a/docs/develop/ruby/workflows/timeouts.mdx b/docs/develop/ruby/workflows/timeouts.mdx index 7013a9d463..ec6c229170 100644 --- a/docs/develop/ruby/workflows/timeouts.mdx +++ b/docs/develop/ruby/workflows/timeouts.mdx @@ -17,7 +17,7 @@ tags: - Temporal SDKs --- -## Workflow timeouts {#workflow-timeouts} +## Workflow timeouts {/* #workflow-timeouts */} Each Workflow timeout controls the maximum duration of a different aspect of a Workflow Execution. @@ -35,7 +35,7 @@ result = my_client.execute_workflow( ) ``` -### Workflow retries {#workflow-retries} +### Workflow retries {/* #workflow-retries */} A Retry Policy can work in cooperation with the timeouts to provide fine controls to optimize the execution experience. diff --git a/docs/develop/ruby/workflows/versioning.mdx b/docs/develop/ruby/workflows/versioning.mdx index c7768f646c..fac41d88f4 100644 --- a/docs/develop/ruby/workflows/versioning.mdx +++ b/docs/develop/ruby/workflows/versioning.mdx @@ -38,7 +38,7 @@ There are two primary Versioning methods that you can use: Temporal's [Worker Versioning](/production-deployment/worker-deployments/worker-versioning) feature allows you to tag your Workers and programmatically roll them out in Deployment Versions, so that old Workers can run old code paths and new Workers can run new code paths. This way, you can pin your Workflows to specific revisions, avoiding the need for patching. -## Versioning with Patching {#ruby-sdk-patching-api} +## Versioning with Patching {/* #ruby-sdk-patching-api */} ### Adding a patch @@ -112,7 +112,7 @@ class MyWorkflow < Temporalio::Workflow::Definition end ``` -### Deprecating patches {#deprecated-patches} +### Deprecating patches {/* #deprecated-patches */} After ensuring that all Workflows started with `v1` code have left retention, you can [deprecate the patch](https://ruby.temporal.io/Temporalio/Workflow.html#deprecate_patch-class_method). @@ -136,7 +136,7 @@ class MyWorkflow < Temporalio::Workflow::Definition end ``` -### Removing a patch {#deploy-new-code} +### Removing a patch {/* #deploy-new-code */} Once the pre-patch Workflows have left retention, you can then safely deploy Workers that no longer use either the `patched()` or `deprecate_patch()` calls: diff --git a/docs/develop/run-a-development-server.mdx b/docs/develop/run-a-development-server.mdx index 336ef0b7d2..5497ace382 100644 --- a/docs/develop/run-a-development-server.mdx +++ b/docs/develop/run-a-development-server.mdx @@ -9,7 +9,7 @@ tags: - Temporal SDKs --- -## How to install the Temporal CLI and run a development server {#run-a-development-server} +## How to install the Temporal CLI and run a development server {/* #run-a-development-server */} This page describes how to install the [Temporal CLI](/cli) and run a development Temporal Service. The local development Temporal Service comes packaged with the [Temporal Web UI](/web-ui). diff --git a/docs/develop/rust/activities/basics.mdx b/docs/develop/rust/activities/basics.mdx index 51de447ced..f683f2b0f3 100644 --- a/docs/develop/rust/activities/basics.mdx +++ b/docs/develop/rust/activities/basics.mdx @@ -11,7 +11,7 @@ tags: - Temporal SDKs --- -## Develop a basic Activity {#develop-activities} +## Develop a basic Activity {/* #develop-activities */} One of the primary things that Workflows do is orchestrate the execution of Activities. An Activity is a normal function or method execution that's intended to execute a single, well-defined action (either short or long-running), such as querying a database, calling a third-party API, or transcoding a media file. @@ -42,7 +42,7 @@ impl GreetingActivities { } ``` -### Define Activity parameters {#activity-parameters} +### Define Activity parameters {/* #activity-parameters */} There is a limit of 6 parameters that an [Activity Definition](/activity-definition) may support. There is also a limit to the total size of the data that ends up encoded into a gRPC message Payload. @@ -113,7 +113,7 @@ impl GreetingActivities { } ``` -### Define Activity return values {#activity-return-values} +### Define Activity return values {/* #activity-return-values */} All data returned from an Activity must be serializable. @@ -158,7 +158,7 @@ impl MyActivities { } ``` -### Customize your Activity Type {#activity-type} +### Customize your Activity Type {/* #activity-type */} Activities have a Type that refers to the Activity name. The Activity name is used to identify Activity Types in the Workflow Execution Event History, Visibility Queries, and Metrics. diff --git a/docs/develop/rust/activities/execution.mdx b/docs/develop/rust/activities/execution.mdx index 05f090897e..5e10c57ea0 100644 --- a/docs/develop/rust/activities/execution.mdx +++ b/docs/develop/rust/activities/execution.mdx @@ -11,7 +11,7 @@ tags: - Activity --- -## Start an Activity Execution {#activity-execution} +## Start an Activity Execution {/* #activity-execution */} Calls to spawn [Activity Executions](/activity-execution) are written within a [Workflow Definition](/workflow-definition). The call to spawn an Activity Execution generates the @@ -48,7 +48,7 @@ impl GreetingWorkflow { } ``` -### Set the required Activity Timeouts {#required-timeout} +### Set the required Activity Timeouts {/* #required-timeout */} Activity Execution semantics rely on several timeout parameters. You need to set at least one of these: @@ -86,7 +86,7 @@ impl GreetingWorkflow { } ``` -### Get the results of an Activity Execution {#get-activity-results} +### Get the results of an Activity Execution {/* #get-activity-results */} Spawning an [Activity Execution](/activity-execution) generates a [ScheduleActivityTask](/references/commands#scheduleactivitytask) Command and returns a `Future` to the Workflow. diff --git a/docs/develop/rust/activities/timeouts.mdx b/docs/develop/rust/activities/timeouts.mdx index fcf3f8cdba..edf8b68483 100644 --- a/docs/develop/rust/activities/timeouts.mdx +++ b/docs/develop/rust/activities/timeouts.mdx @@ -17,7 +17,7 @@ tags: - Temporal SDKs --- -## Set Activity timeouts {#activity-timeouts} +## Set Activity timeouts {/* #activity-timeouts */} Each Activity timeout controls the maximum duration of a different aspect of an Activity Execution. @@ -45,7 +45,7 @@ let greeting = ctx.start_activity( ); ```` -### Set an Activity Retry Policy {#activity-retries} +### Set an Activity Retry Policy {/* #activity-retries */} A Retry Policy works together with timeouts to provide fine-grained control over Activity failure handling. Activities automatically use a default [Retry Policy](/encyclopedia/retry-policies) unless you provide a custom one. @@ -68,7 +68,7 @@ let language = ctx.start_activity( ); ``` -### Override the retry interval with `explicit_delay` {#next-retry-delay} +### Override the retry interval with `explicit_delay` {/* #next-retry-delay */} To override the next retry interval set by the current policy, return a failure from an Activity with a custom next retry delay. That value replaces the interval the Retry Policy would otherwise use for the next retry attempt. This is useful when retry timing depends on runtime state such as the current attempt number. @@ -99,7 +99,7 @@ impl TestGreetActivities { } ``` -## Heartbeat an Activity {#activity-heartbeats} +## Heartbeat an Activity {/* #activity-heartbeats */} An [Activity Heartbeat](/encyclopedia/detecting-activity-failures#activity-heartbeat) is a signal from the [Worker Process](/workers#worker-process) executing the Activity to the [Temporal Service](/temporal-service). Each heartbeat tells the service that the [Activity Execution](/activity-execution) is still making progress and that the Worker has not crashed. If the service does not receive a heartbeat within the configured [Heartbeat Timeout](/encyclopedia/detecting-activity-failures#heartbeat-timeout), the Activity can time out and be retried according to its Retry Policy. @@ -121,7 +121,7 @@ pub async fn greet(ctx: ActivityContext, name: String) -> Result Result<(), Box> { -## Connect to Temporal Cloud {#connect-to-temporal-cloud} +## Connect to Temporal Cloud {/* #connect-to-temporal-cloud */} You can connect to Temporal Cloud using either an API key or mTLS. Connection to Temporal Cloud or any secured Temporal Service requires additional connection options compared to connecting to an unsecured local development instance: @@ -335,7 +335,7 @@ async fn main() -> Result<(), Box> { -## Start a Workflow Execution {#start-workflow-execution} +## Start a Workflow Execution {/* #start-workflow-execution */} To start a Workflow Execution, supply: @@ -359,7 +359,7 @@ let handle = client.start_workflow( ).await?; ``` -### Set a Workflow's Task Queue {#set-task-queue} +### Set a Workflow's Task Queue {/* #set-task-queue */} In most cases, the Task Queue is a required Workflow option. @@ -379,7 +379,7 @@ let handle = client ).await?; ``` -### Set a Workflow Id {#workflow-id} +### Set a Workflow Id {/* #workflow-id */} You must set a [Workflow Id](/workflow-execution/workflowid-runid#workflow-id). @@ -399,7 +399,7 @@ let handle = client ).await?; ``` -## Get the results of a Workflow Execution {#get-workflow-results} +## Get the results of a Workflow Execution {/* #get-workflow-results */} If starting a Workflow succeeds, you get a Workflow handle. You can use that handle to wait for the result, describe the Workflow, or interact with it through Signals, Queries, and Updates. diff --git a/docs/develop/rust/nexus/feature-guide.mdx b/docs/develop/rust/nexus/feature-guide.mdx index 9145cbf1fb..d63a112f48 100644 --- a/docs/develop/rust/nexus/feature-guide.mdx +++ b/docs/develop/rust/nexus/feature-guide.mdx @@ -15,7 +15,7 @@ tags: [Nexus](/nexus) is a tool for coordinating asynchronous operations between Temporal and external systems. Service handlers allow Workflows to receive inbound requests through Nexus. -## Call a Nexus Operation from a Workflow {#call-nexus-operation} +## Call a Nexus Operation from a Workflow {/* #call-nexus-operation */} You can start a Nexus operation from a Workflow using `ctx.start_nexus_operation()`: diff --git a/docs/develop/rust/workers/worker-process.mdx b/docs/develop/rust/workers/worker-process.mdx index ad7cdaf84c..4a4dee76bd 100644 --- a/docs/develop/rust/workers/worker-process.mdx +++ b/docs/develop/rust/workers/worker-process.mdx @@ -10,7 +10,7 @@ tags: - Worker --- -## Run a Worker Process {#run-a-dev-worker} +## Run a Worker Process {/* #run-a-dev-worker */} The [Worker Process](/workers#worker-process) is where Workflow and Activity code executes. A Worker polls a specific [Task Queue](/task-queue), processes Tasks from that queue, and reports results back to the Temporal Service. @@ -55,7 +55,7 @@ pub async fn run() -> Result<(), Box> { } ``` -### Register types {#register-types} +### Register types {/* #register-types */} All Workers polling the same Task Queue name must be registered to handle the exact same Workflow Types and Activity Types. If a Worker receives a Task for a type it does not know how to execute, that Task fails, but the Workflow Execution itself does not necessarily fail. diff --git a/docs/develop/rust/workflows/basics.mdx b/docs/develop/rust/workflows/basics.mdx index c1357ef412..705eee741b 100644 --- a/docs/develop/rust/workflows/basics.mdx +++ b/docs/develop/rust/workflows/basics.mdx @@ -11,7 +11,7 @@ tags: - Temporal SDKs --- -## How to develop a Workflow {#develop-workflows} +## How to develop a 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). @@ -50,11 +50,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: @@ -71,7 +71,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. -### Run method {#run-method} +### Run method {/* #run-method */} The `#[run]` method is required and contains the main Workflow logic. It: @@ -94,7 +94,7 @@ async fn run(ctx: &mut WorkflowContext) -> WorkflowResult { } ``` -## Define Workflow parameters {#workflow-parameters} +## Define Workflow parameters {/* #workflow-parameters */} Temporal Workflows may have any number of custom parameters. However, we strongly recommend that structs 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. @@ -135,7 +135,7 @@ impl ProcessingWorkflow { All Workflow input should be serializable by `serde`. -## Define Workflow return parameters {#workflow-return-values} +## Define Workflow return parameters {/* #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. @@ -154,7 +154,7 @@ async fn run(ctx: &mut WorkflowContext) -> WorkflowResult) -> WorkflowResult { } ``` -## Access Workflow State {#workflow-state} +## Access Workflow State {/* #workflow-state */} Use `ctx.state()` for read-only access and `ctx.state_mut()` for mutable access to your Workflow state: @@ -248,7 +248,7 @@ async fn run(ctx: &mut WorkflowContext) -> WorkflowResult { In synchronous [`Signal`](/develop/rust/workflows/message-passing#signals) and [`Update`](/develop/rust/workflows/message-passing#updates) handlers, you can mutate state directly via `&mut self`. -## Workflow return types {#return-types} +## Workflow return types {/* #return-types */} The `#[run]` method must return `WorkflowResult`. This is a type alias for `Result`. diff --git a/docs/develop/rust/workflows/cancellation.mdx b/docs/develop/rust/workflows/cancellation.mdx index 3bad2f6a8f..74a7144b39 100644 --- a/docs/develop/rust/workflows/cancellation.mdx +++ b/docs/develop/rust/workflows/cancellation.mdx @@ -35,7 +35,7 @@ Terminating a Workflow forcefully stops Workflow Execution. This action resemble In most cases, canceling is preferable because it allows the Workflow to finish gracefully. Terminate only if the Workflow is stuck and cannot be canceled normally. -## Cancel a Workflow Execution {#cancellation} +## Cancel a Workflow Execution {/* #cancellation */} Canceling a Workflow provides a graceful way to stop Workflow Execution. This action resembles sending a `SIGTERM` to a process. @@ -57,7 +57,7 @@ let handle = client.start_workflow( handle.cancel(WorkflowCancelOptions::builder().reason("No longer needed").build()).await?; ```` -### Cancel an Activity from a Workflow {#cancel-activity} +### Cancel an Activity from a Workflow {/* #cancel-activity */} Canceling an Activity from within a Workflow requires that the Activity Execution sends Heartbeats and sets a Heartbeat Timeout. If the Heartbeat is not invoked, the Activity cannot receive a cancellation request. When any non-immediate @@ -146,7 +146,7 @@ impl CancellationWorkflow { } ``` -## Terminate a Workflow Execution {#termination} +## Terminate a Workflow Execution {/* #termination */} Terminating a Workflow forcefully stops Workflow Execution. This action resembles killing a process. @@ -171,7 +171,7 @@ handle.terminate(WorkflowTerminateOptions::builder() ``` -## Reset a Workflow Execution {#reset} +## Reset a Workflow Execution {/* #reset */} Resetting a Workflow Execution terminates the current Workflow Execution and starts a new Workflow Execution from a point you specify in its Event History. Use reset when a Workflow is blocked due to a non-deterministic error or other diff --git a/docs/develop/rust/workflows/child-workflows.mdx b/docs/develop/rust/workflows/child-workflows.mdx index 78ecb0f722..d2e98266e8 100644 --- a/docs/develop/rust/workflows/child-workflows.mdx +++ b/docs/develop/rust/workflows/child-workflows.mdx @@ -18,7 +18,7 @@ This page shows how to do the following: - [Start a Child Workflow execution](#start-child-workflow) - [Set a Parent Close Policy](#parent-close-policy) -## Start a Child Workflow execution {#start-child-workflow} +## Start a Child Workflow execution {/* #start-child-workflow */} A [Child Workflow Execution](/child-workflows) is a Workflow Execution that is scheduled from within another Workflow using a Child Workflow API. @@ -137,7 +137,7 @@ pub async fn run(ctx: &mut WorkflowContext) -> WorkflowResult Result<(), Box> { - Query handlers can't mutate Workflow state. - Query handlers can't perform async operations, like executing Activities. -### Signal handlers {#signals} +### Signal handlers {/* #signals */} A [Signal](/sending-messages#sending-signals) is an asynchronous message sent to a running Workflow Execution to change its state and control its flow: @@ -193,7 +193,7 @@ async fn main() -> Result<(), Box> { * Signal handlers do not return values. * They can trigger async work (Activities, timers) depending on SDK capabilities. -### Update handlers and validators {#updates} +### Update handlers and validators {/* #updates */} An [Update](/sending-messages#sending-updates) is a trackable synchronous request sent to a running Workflow Execution. It can change the Workflow state, control its flow, and return a result. The sender must wait until the Worker accepts or rejects the Update. The sender may wait further to receive a returned value or an exception if something goes wrong: @@ -251,7 +251,7 @@ impl GreetingsWorkflow { - When a Validator raises an error, the Update is rejected and `WorkflowExecutionUpdateAccepted` won't be added to the Event History. The caller receives an "Update failed" error. - Update and Signal handlers can be async, letting you use Activities, Child Workflows, and more. See [Async handlers](#async-handlers) for safe usage guidelines. -## Send messages {#send-messages} +## Send messages {/* #send-messages */} To send Queries, Signals, or Updates, use a Workflow handle from the client: @@ -265,7 +265,7 @@ let wf_handle = client.start_workflow( ).await?; ``` -### Send a Query {#send-query} +### Send a Query {/* #send-query */} ```rust let supported_languages = wf_handle.query( @@ -279,7 +279,7 @@ let supported_languages = wf_handle.query( - You can send Queries to closed Workflow Executions within a Namespace's Workflow retention period. This includes Workflows that have completed, failed, or timed out. Querying terminated Workflows is not safe and, therefore, not supported. - A Worker must be online and polling the Task Queue to process a Query. -### Send a Signal {#send-signal} +### Send a Signal {/* #send-signal */} You can send a Signal to a Workflow Execution from a Temporal Client or from another Workflow Execution. However, you can only send Signals to Workflow Executions that haven’t closed. @@ -304,7 +304,7 @@ let signal_res = ctx .await; ``` -### Signal-With-Start {#signal-with-start} +### Signal-With-Start {/* #signal-with-start */} ```rust let signal_input = Payloads { @@ -322,7 +322,7 @@ let wf_handle = client.start_workflow( ).await?; ``` -### Send an Update {#send-update-from-client} +### Send an Update {/* #send-update-from-client */} An Update is a synchronous, blocking call that can change Workflow state, control its flow, and return a result. @@ -364,9 +364,9 @@ let update_handle = main_wf_handle.start_update( - Updates are synchronous and return results. - Worker must accept the Update before it proceeds. -## Message handler patterns {#message-handler-patterns} +## Message handler patterns {/* #message-handler-patterns */} -### Async handlers {#async-handlers} +### Async handlers {/* #async-handlers */} Signal and Update handlers can be `async fn` as well as `fn`. Using `async fn` allows you to use await with Activities, Child Workflows, Timers, etc. This expands the possibilities for what can be done by a handler, but it also means that handler executions and your main Workflow method are all running concurrently, with switching occurring between them at await calls. diff --git a/docs/develop/rust/workflows/timeouts.mdx b/docs/develop/rust/workflows/timeouts.mdx index d5d1129d43..a69023b17e 100644 --- a/docs/develop/rust/workflows/timeouts.mdx +++ b/docs/develop/rust/workflows/timeouts.mdx @@ -17,7 +17,7 @@ tags: - Temporal SDKs --- -## Workflow timeouts {#workflow-timeouts} +## Workflow timeouts {/* #workflow-timeouts */} Each Workflow timeout controls the maximum duration of a different aspect of a Workflow Execution. @@ -57,7 +57,7 @@ let wf_handle = client.start_workflow( ).await?; ``` -## Workflow retries {#workflow-retries} +## Workflow retries {/* #workflow-retries */} A Retry Policy can be used alongside timeouts to control how Workflow Executions are retried after failure. diff --git a/docs/develop/typescript/activities/asynchronous-activity.mdx b/docs/develop/typescript/activities/asynchronous-activity.mdx index 7982b09712..afe8e4ab2d 100644 --- a/docs/develop/typescript/activities/asynchronous-activity.mdx +++ b/docs/develop/typescript/activities/asynchronous-activity.mdx @@ -13,7 +13,7 @@ tags: description: Asynchronously complete an Activity in Temporal by enabling the Activity Function to return before the Activity Execution finishes, using AsyncCompletionClient. --- -## How to asynchronously complete an Activity {#asynchronous-activity-completion} +## How to asynchronously complete an Activity {/* #asynchronous-activity-completion */} [Asynchronous Activity Completion](/activity-execution#asynchronous-activity-completion) enables the Activity Function to return without the Activity Execution completing. @@ -47,7 +47,7 @@ async function doSomeWork(taskToken: Uint8Array): Promise { ``` -## Local Activities {#local-activities} +## Local Activities {/* #local-activities */} To call [Local Activities](/local-activity) in TypeScript, use [`proxyLocalActivities`](https://typescript.temporal.io/api/namespaces/workflow/#proxylocalactivities). diff --git a/docs/develop/typescript/activities/basics.mdx b/docs/develop/typescript/activities/basics.mdx index c8af41e72d..73e539cdd9 100644 --- a/docs/develop/typescript/activities/basics.mdx +++ b/docs/develop/typescript/activities/basics.mdx @@ -11,7 +11,7 @@ tags: - Activity --- -## How to develop an Activity {#develop-activities} +## How to develop an Activity {/* #develop-activities */} One of the primary things that Workflows do is orchestrate the execution of Activities. An Activity is a normal function or method execution that's intended to execute a single, well-defined action (either short or long-running), such as @@ -34,7 +34,7 @@ export async function greet(name: string): Promise { ``` -## How to develop Activity Parameters {#activity-parameters} +## How to develop Activity Parameters {/* #activity-parameters */} There is no explicit limit to the total number of parameters that an [Activity Definition](/activity-definition) may support. However, there is a limit to the total size of the data that ends up encoded into a gRPC message Payload. @@ -65,7 +65,7 @@ export async function greet(name: string): Promise { ``` -## How to define Activity return values {#activity-return-values} +## How to define Activity return values {/* #activity-return-values */} All data returned from an Activity must be serializable. @@ -84,7 +84,7 @@ export async function greet(name: string): Promise { } ``` -## How to customize your Activity Type {#activity-type} +## How to customize your Activity Type {/* #activity-type */} Activities have a Type that are referred to as the Activity name. The following examples demonstrate how to set a custom name for your Activity Type. @@ -112,7 +112,7 @@ async function run() { ``` -## Important design patterns for Activities {#activity-design-patterns} +## Important design patterns for Activities {/* #activity-design-patterns */} The following are some important (and frequently requested) patterns for using our Activities APIs. These patterns address common needs and use cases. diff --git a/docs/develop/typescript/activities/execution.mdx b/docs/develop/typescript/activities/execution.mdx index e3827ef0a9..efe160684b 100644 --- a/docs/develop/typescript/activities/execution.mdx +++ b/docs/develop/typescript/activities/execution.mdx @@ -11,7 +11,7 @@ tags: - Activity --- -## How to start an Activity Execution {#activity-execution} +## How to start an Activity Execution {/* #activity-execution */} Calls to spawn [Activity Executions](/activity-execution) are written within a [Workflow Definition](/workflow-definition). In TypeScript, you never call an Activity function directly. Instead, you @@ -55,14 +55,14 @@ in and the value that comes back. This history is what allows Temporal to recove the entire history must be stored and replayed, avoid passing large objects as Activity inputs or return values. Keeping payloads small will help your Workflows replay and recover efficiently. ::: -## How to set the required Activity Timeouts {#required-timeout} +## How to set the required Activity Timeouts {/* #required-timeout */} Activity Execution semantics rely on several parameters. The only required value that needs to be set is either a [Schedule-To-Close Timeout](/encyclopedia/detecting-activity-failures#schedule-to-close-timeout) or a [Start-To-Close Timeout](/encyclopedia/detecting-activity-failures#start-to-close-timeout). These values are set in the Activity Options. -## How to get the results of an Activity Execution {#get-activity-results} +## How to get the results of an Activity Execution {/* #get-activity-results */} The call to spawn an [Activity Execution](/activity-execution) generates the [ScheduleActivityTask](/references/commands#scheduleactivitytask) Command and provides the Workflow with an Awaitable. diff --git a/docs/develop/typescript/activities/standalone-activities.mdx b/docs/develop/typescript/activities/standalone-activities.mdx index c0e2599e38..7443678522 100644 --- a/docs/develop/typescript/activities/standalone-activities.mdx +++ b/docs/develop/typescript/activities/standalone-activities.mdx @@ -55,7 +55,7 @@ This documentation uses source code from the [standalone-activity](https://githu ::: -## Get Started with Standalone Activities {#get-started} +## Get Started with Standalone Activities {/* #get-started */} Prerequisites: @@ -121,7 +121,7 @@ standalone-activity/src/ └── worker.ts ``` -## Write an Activity Function {#write-activity} +## Write an Activity Function {/* #write-activity */} The way you write a Standalone Activity is identical to how you write an Activity to be orchestrated by a Workflow. In fact, an Activity can be executed both as a Standalone Activity and as a Workflow @@ -140,7 +140,7 @@ export async function greet(name: string): Promise { } ``` -## Run a Worker with the Activity registered {#run-worker} +## Run a Worker with the Activity registered {/* #run-worker */} Running a Worker for Standalone Activities is the same as running a Worker for Workflow Activities — you create a Worker, register the Activity, and run the Worker. The Worker doesn't need to know @@ -185,7 +185,7 @@ npm run start Leave this terminal running - the Worker needs to stay up to process activities. -## Run the sample client {#run-sample} +## Run the sample client {/* #run-sample */} The sample file [standalone-activity/src/execute.ts](https://github.com/temporalio/samples-typescript/blob/main/standalone-activity/src/execute.ts) contains a program demonstrating various ways to execute Standalone Activities and fetch results. The code in @@ -201,7 +201,7 @@ To run it: npm run execute ``` -## Execute a Standalone Activity with type checking {#execute-activity-type-checking} +## Execute a Standalone Activity with type checking {/* #execute-activity-type-checking */} Start by [creating a Temporal Client](/develop/typescript/client/temporal-client). Then call [`client.activity.typed()`](https://typescript.temporal.io/api/classes/client.ActivityClient#typed) @@ -247,7 +247,7 @@ const result = await activitiesClient.execute('greet', { }); ``` -## Execute a Standalone Activity without type checking {#execute-activity-no-type-checking} +## Execute a Standalone Activity without type checking {/* #execute-activity-no-type-checking */} Since Activity types are not always available, the [`start`](https://typescript.temporal.io/api/classes/client.ActivityClient#start) and [`execute`](https://typescript.temporal.io/api/classes/client.ActivityClient#execute) methods can be @@ -274,7 +274,7 @@ temporal activity execute \ --input '"World"' ``` -## Start a Standalone Activity without waiting for the result {#start-activity} +## Start a Standalone Activity without waiting for the result {/* #start-activity */} Starting a Standalone Activity means sending a request to the Temporal Server to durably enqueue your Activity job, without waiting for it to be executed by your Worker. @@ -302,7 +302,7 @@ temporal activity start \ --input '"World"' ``` -## Get a handle to an existing Standalone Activity {#get-activity-handle} +## Get a handle to an existing Standalone Activity {/* #get-activity-handle */} You can also use [`getHandle`](https://typescript.temporal.io/api/classes/client.ActivityClient#gethandle) to create a handle to a previously started Standalone Activity. Because the client doesn't know @@ -316,7 +316,7 @@ const newHandle = client.activity.getHandle(activityId); You can now use the handle to wait for the result, describe, cancel, or terminate the Activity. -## Wait for the result of a Standalone Activity {#get-activity-result} +## Wait for the result of a Standalone Activity {/* #get-activity-result */} Under the hood, calling [`execute`](https://typescript.temporal.io/api/interfaces/client.TypedActivityClient#execute) is the same as calling [`start`](https://typescript.temporal.io/api/interfaces/client.TypedActivityClient#start) @@ -333,7 +333,7 @@ Or use the Temporal CLI to wait for a result by Activity Id: temporal activity result --activity-id my-standalone-activity-id ``` -## List Standalone Activities {#list-activities} +## List Standalone Activities {/* #list-activities */} Use [`list`](https://typescript.temporal.io/api/classes/client.ActivityClient#list) method of the client to list @@ -373,7 +373,7 @@ The query parameter accepts the same [List Filter](/list-filter) syntax used for Visibility](/visibility). For example, "ActivityType = 'MyActivity' AND Status = 'Running'". -## Count Standalone Activities {#count-activities} +## Count Standalone Activities {/* #count-activities */} Use [`count`](https://typescript.temporal.io/api/classes/client.ActivityClient#count) method of the client @@ -403,7 +403,7 @@ Or use the Temporal CLI: temporal activity count ``` -## Run Standalone Activities with Temporal Cloud {#run-standalone-activities-temporal-cloud} +## Run Standalone Activities with Temporal Cloud {/* #run-standalone-activities-temporal-cloud */} The code samples on this page use [`loadClientConnectConfig`](https://typescript.temporal.io/api/namespaces/envconfig#loadclientconnectconfig), so the same code works against Temporal Cloud - just configure the connection via environment variables or a TOML diff --git a/docs/develop/typescript/activities/timeouts.mdx b/docs/develop/typescript/activities/timeouts.mdx index 9062bee304..99f17a4d95 100644 --- a/docs/develop/typescript/activities/timeouts.mdx +++ b/docs/develop/typescript/activities/timeouts.mdx @@ -25,7 +25,7 @@ This page shows how to do the following: - [Heartbeat an Activity](#activity-heartbeats) - [Activity Heartbeat Timeout](#activity-heartbeat-timeout) -## Activity Timeouts {#activity-timeouts} +## Activity Timeouts {/* #activity-timeouts */} **How to set Activity Timeouts using the Temporal TypeScript SDK** @@ -53,7 +53,7 @@ const { myActivity } = proxyActivities({ }); ``` -## Activity Retry Policy {#activity-retries} +## Activity Retry Policy {/* #activity-retries */} **How to set an Activity Retry Policy using the Temporal TypeScript SDK** @@ -73,7 +73,7 @@ const { myActivity } = proxyActivities({ }); ``` -## Activity next Retry delay {#activity-next-retry-delay} +## Activity next Retry delay {/* #activity-next-retry-delay */} **How to override the next Retry delay following an Activity failure using the Temporal TypeScript SDK** @@ -89,7 +89,7 @@ throw ApplicationFailure.create({ }); ``` -## Heartbeat an Activity {#activity-heartbeats} +## Heartbeat an Activity {/* #activity-heartbeats */} **How to Heartbeat an Activity using the Temporal TypeScript SDK** @@ -147,7 +147,7 @@ export async function myActivity(): Promise { } ``` -## Activity Heartbeat Timeout {#activity-heartbeat-timeout} +## Activity Heartbeat Timeout {/* #activity-heartbeat-timeout */} **How to set a Heartbeat Timeout using the Temporal TypeScript SDK** diff --git a/docs/develop/typescript/best-practices/converters-and-encryption.mdx b/docs/develop/typescript/best-practices/converters-and-encryption.mdx index 5374167dd8..1bd3a149bc 100644 --- a/docs/develop/typescript/best-practices/converters-and-encryption.mdx +++ b/docs/develop/typescript/best-practices/converters-and-encryption.mdx @@ -129,7 +129,7 @@ const client = new Client({ You can now use a variety of data types in arguments. -## How to use a custom payload converter in TypeScript {#custom-payload-conversion} +## How to use a custom payload converter in TypeScript {/* #custom-payload-conversion */} To support custom Payload conversion, create a [custom Payload Converter](/payload-converter#composite-data-converters) and configure the Data Converter to use it in your Client options. You can use Custom Payload Converters to change how application objects get serialized to binary Payload. To handle custom data types that are not natively JSON-serializable (e.g., `BigInt`, `Date`, or binary data), you can create a custom Payload Converter. A Custom Payload Converter is responsible for converting your custom data types to a payload format that Temporal can manage. diff --git a/docs/develop/typescript/best-practices/debugging.mdx b/docs/develop/typescript/best-practices/debugging.mdx index e30f3cecdb..64109229f2 100644 --- a/docs/develop/typescript/best-practices/debugging.mdx +++ b/docs/develop/typescript/best-practices/debugging.mdx @@ -17,11 +17,11 @@ import { CaptionedImage } from '@site/src/components'; The Debugging section of the Temporal TypeScript SDK developer's guide covers tools for debugging and how to troubleshoot common issues. -## How to debug in a development environment {#debug-in-a-development-environment} +## How to debug in a development environment {/* #debug-in-a-development-environment */} 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 production environment {#debug-in-a-production-environment} +## How to debug in a production environment {/* #debug-in-a-production-environment */} You can debug production Workflows using: @@ -36,7 +36,7 @@ For information on setting up SDK metrics, see [Metrics](/develop/typescript/pla Debug Server performance with [Cloud metrics](/cloud/metrics/) or [self-hosted Server metrics](/self-hosted-guide/production-checklist#scaling-and-metrics). -## How to troubleshoot common issues in the TypeScript SDK {#troubleshoot-common-issues} +## How to troubleshoot common issues in the TypeScript SDK {/* #troubleshoot-common-issues */} {/* The following was ported from \docs-src\typescript\troubleshooting.md */} diff --git a/docs/develop/typescript/best-practices/entity-pattern.mdx b/docs/develop/typescript/best-practices/entity-pattern.mdx index 5948efe43e..6e359e76de 100644 --- a/docs/develop/typescript/best-practices/entity-pattern.mdx +++ b/docs/develop/typescript/best-practices/entity-pattern.mdx @@ -12,7 +12,7 @@ tags: description: Implement the Single-Entity Design Pattern in TypeScript to manage Workflow iterations and handle Signals, ensuring efficient Workflow Execution with updates. --- -### Single-entity design pattern in TypeScript {#single-entity-pattern} +### Single-entity design pattern in TypeScript {/* #single-entity-pattern */} The following is a simple pattern that represents a single entity. It tracks the number of iterations regardless of frequency, and calls `continueAsNew` while properly handling pending updates from Signals. diff --git a/docs/develop/typescript/best-practices/testing-suite.mdx b/docs/develop/typescript/best-practices/testing-suite.mdx index 2b2cfe8214..6952e77ab4 100644 --- a/docs/develop/typescript/best-practices/testing-suite.mdx +++ b/docs/develop/typescript/best-practices/testing-suite.mdx @@ -27,7 +27,7 @@ We generally recommend writing the majority of your tests as integration tests. Because the test server supports skipping time, use the test server for both end-to-end and integration tests with Workers. -## Test frameworks {#test-frameworks} +## Test frameworks {/* #test-frameworks */} Some SDKs have support or examples for popular test frameworks, runners, or libraries. @@ -44,12 +44,12 @@ TypeScript has sample tests for [Jest](https://jestjs.io/) and [Mocha](https://m - [Sample test file](https://github.com/temporalio/samples-typescript/blob/main/activities-examples/src/mocha/workflows.test.ts) - Test coverage library: [`@temporalio/nyc-test-coverage`](https://github.com/temporalio/sdk-typescript/tree/main/packages/nyc-test-coverage) -## Testing Activities {#test-activities} +## Testing Activities {/* #test-activities */} An Activity can be tested with a mock Activity environment, which provides a way to mock the Activity context, listen to Heartbeats, and cancel the Activity. This behavior allows you to test the Activity in isolation by calling it directly, without needing to create a Worker to run the Activity. -### Run an Activity {#run-an-activity} +### Run an Activity {/* #run-an-activity */} If an Activity references its context, you need to mock that context when testing in isolation. @@ -76,7 +76,7 @@ const result = await env.run(activityFoo, 5, 35); assert.equal(result, 42); ``` -### Listen to Heartbeats {#listen-to-heartbeats} +### Listen to Heartbeats {/* #listen-to-heartbeats */} When an Activity sends a Heartbeat, be sure that you can see the Heartbeats in your test code so that you can verify them. @@ -102,7 +102,7 @@ env.on('heartbeat', (d: unknown) => { await env.run(activityFoo); ``` -### Cancel an Activity {#cancel-an-activity} +### Cancel an Activity {/* #cancel-an-activity */} If an Activity is supposed to react to a Cancellation, you can test whether it reacts correctly by canceling it. @@ -131,9 +131,9 @@ await assert.rejects(env.run(activityFoo), (err) => { }); ``` -## Testing Workflows {#test-workflows} +## Testing Workflows {/* #test-workflows */} -### How to mock Activities {#mock-activities} +### How to mock Activities {/* #mock-activities */} Mock the Activity invocation when unit testing your Workflows. @@ -156,7 +156,7 @@ const worker = await Worker.create({ }); ``` -### How to skip time {#skip-time} +### How to skip time {/* #skip-time */} Some long-running Workflows can persist for months or even years. Implementing the test framework allows your Workflow code to skip time and complete your tests in seconds rather than the Workflow's specified amount. @@ -169,7 +169,7 @@ Time is a global property of an instance of `TestWorkflowEnvironment`: skipping If you need different time behaviors for different tests, run your tests in a series or with separate instances of the test server. For example, you could run all tests with automatic time skipping in parallel, and then all tests with manual time skipping in series, and then all tests without time skipping in parallel. -#### Set up time skipping {#setting-up} +#### Set up time skipping {/* #setting-up */} Set up the time-skipping test framework in the SDK of your choice. @@ -223,7 +223,7 @@ test('workflowFoo', async () => { This test uses the test connection to create a Worker, runs the Worker until the Workflow is complete, and then makes an assertion about the Workflow's result. The Workflow is executed using `testEnv.client.workflow`, which is connected to the test server. -#### Skip time automatically {#automatic-method} +#### Skip time automatically {/* #automatic-method */} You can skip time automatically in the SDK of your choice. Start a test server process that skips time as needed. @@ -264,7 +264,7 @@ test('sleep completes almost immediately', async () => { }); ``` -#### Skip time manually {#manual-method} +#### Skip time manually {/* #manual-method */} Skip time manually in the SDK of your choice. @@ -326,7 +326,7 @@ test('sleeperWorkflow counts days correctly', async () => { }); ``` -#### Skip time in Activities {#skip-time-in-activities} +#### Skip time in Activities {/* #skip-time-in-activities */} Skip time in Activities in the SDK of your choice. @@ -410,7 +410,7 @@ it('sends reminder email if processOrder does not complete in time', async () => ``` -### Test functions in Workflow context {#workflow-context} +### Test functions in Workflow context {/* #workflow-context */} For a function or method to run in the Workflow context (where it's possible to get the current Workflow info, or running inside the sandbox in the case of TypeScript or Python), it needs to be run by the Worker as if it were a Workflow. @@ -466,7 +466,7 @@ export async function functionToTest(): Promise { } ``` -### Assert in Workflow {#assert-in-workflow} +### Assert in Workflow {/* #assert-in-workflow */} The `assert` statement is a convenient way to insert debugging assertions into the Workflow context. @@ -512,7 +512,7 @@ await worker.runUntil( ); ``` -## How to Replay a Workflow Execution {#replay} +## How to Replay a Workflow Execution {/* #replay */} Replay recreates the exact state of a Workflow Execution. You can replay a Workflow from the beginning of its Event History. diff --git a/docs/develop/typescript/client/namespaces.mdx b/docs/develop/typescript/client/namespaces.mdx index 830ca40f70..0053703728 100644 --- a/docs/develop/typescript/client/namespaces.mdx +++ b/docs/develop/typescript/client/namespaces.mdx @@ -13,7 +13,7 @@ tags: description: Efficiently create and manage Namespaces on Temporal using CLI or SDK APIs. Isolate Workflow Executions, control access with custom Authorizers, and manage via Temporal Cloud UI or CLI. --- -## How to create and manage Namespaces {#namespaces} +## How to create and manage Namespaces {/* #namespaces */} You can create, update, deprecate or delete your [Namespaces](/namespaces) using either the Temporal CLI or SDK APIs. @@ -30,7 +30,7 @@ Use a custom [Authorizer](/self-hosted-guide/security#authorizer-plugin) on your You must register a Namespace with the Temporal Service before setting it in the Temporal Client. -### How to register Namespaces {#register-namespace} +### How to register Namespaces {/* #register-namespace */} Registering a Namespace creates a Namespace on the Temporal Service or Temporal Cloud. @@ -41,7 +41,7 @@ Note that these APIs and Temporal CLI commands will not work with Temporal Cloud Use a custom [Authorizer](/self-hosted-guide/security#authorizer-plugin) on your Frontend Service in the Temporal Service to set restrictions on who can create, update, or deprecate Namespaces. -### How to manage Namespaces {#manage-namespaces} +### How to manage Namespaces {/* #manage-namespaces */} You can get details for your Namespaces, update Namespace configuration, and deprecate or delete your Namespaces. diff --git a/docs/develop/typescript/client/temporal-client.mdx b/docs/develop/typescript/client/temporal-client.mdx index a2db84e6dd..379eb7b079 100644 --- a/docs/develop/typescript/client/temporal-client.mdx +++ b/docs/develop/typescript/client/temporal-client.mdx @@ -48,7 +48,7 @@ different type of connection than connecting from a Worker. The sections an Activity. See [Connect to Temporal Service from a Worker](#connect-to-temporal-service-from-a-worker) for details on connecting from a Worker. -## Connect to development Temporal Service {#connect-to-development-service} +## Connect to development Temporal Service {/* #connect-to-development-service */} To connect to a development Temporal service from a Temporal Application or from within an Activity, import the [`Connection` class](https://typescript.temporal.io/api/classes/client.Connection) from `@temporalio/client` and use @@ -266,7 +266,7 @@ const client = new Client({ -## Connect to Temporal Cloud {#connect-to-temporal-cloud} +## Connect to Temporal Cloud {/* #connect-to-temporal-cloud */} You can connect to Temporal Cloud using either an [API key](/cloud/api-keys) or through mTLS. Connection to Temporal Cloud or any secured Temporal Service requires additional connection options compared to connecting to an unsecured @@ -480,7 +480,7 @@ connection.setApiKey(); -## Connect to Temporal Service from a Worker {#connect-to-temporal-service-from-a-worker} +## Connect to Temporal Service from a Worker {/* #connect-to-temporal-service-from-a-worker */} Connecting to Temporal Service from a Worker requires the same set of connections options as connecting from a Temporal Application or from within an Activity, but the connection type is different. When connecting from a Worker, you create @@ -607,14 +607,14 @@ communication with the Temporal Service. This section explains the differences b respective use cases. For detailed information about each class, refer to the [Temporal TypeScript API documentation](https://typescript.temporal.io/api/namespaces/client). -### NativeConnection vs. Connection {#native-connection-vs-connection} +### NativeConnection vs. Connection {/* #native-connection-vs-connection */} The TypeScript SDK provides two types of connection classes to connect to the Temporal Service: `NativeConnection` and `Connection`. The `NativeConnection` class is used to connect from a Worker, while the `Connection` class is used to connect from a Temporal Application or from within an Activity, typically through a `Client` object. Both connection classes accept the same set of connection options. -### Connection vs. Client {#connection-vs-client} +### Connection vs. Client {/* #connection-vs-client */} A `Client` object is a high-level, lightweight abstraction that simplifies interaction with the Temporal Service. It internally manages a `Connection` object to handle the low-level communication details. The `Client` class provides @@ -629,7 +629,7 @@ When instantiating a `Connection`, you specify most connection options except fo Service endpoint, TLS settings, and authentication credentials. When instantiating a `Client`, you provide the `Connection` object and the Namespace you want to connect to, along with other client options. -## Start Workflow Execution {#start-workflow-execution} +## Start Workflow Execution {/* #start-workflow-execution */} **How to start a Workflow Execution using the Typescript SDK** @@ -673,7 +673,7 @@ and Workflow Definition. Workflow Execution run in a separate V8 isolate context in order to provide a [deterministic runtime](/workflow-definition#deterministic-constraints). -### Set a Workflow's Task Queue {#set-task-queue} +### Set a Workflow's Task Queue {/* #set-task-queue */} In most SDKs, the only Workflow Option that must be set is the name of the [Task Queue](/task-queue). @@ -757,7 +757,7 @@ Optionally, in Workflow code, when calling an Activity, you can specify the Task to `proxyActivities()`, `startChild()`, or `executeChild()`. If you do not specify `taskQueue`, the TypeScript SDK places Activity and Child Workflow Tasks in the same Task Queue as the Workflow Task Queue. -### Set a Workflow Id {#workflow-id} +### Set a Workflow Id {/* #workflow-id */} Although it is not required, we recommend providing your own [Workflow Id](/workflow-execution/workflowid-runid#workflow-id) that maps to a business process or business entity @@ -776,7 +776,7 @@ const handle = await client.workflow.start(example, { This starts a new Client with the given Workflow Id, Task Queue name, and an argument. -### Get the results of a Workflow Execution {#get-workflow-results} +### Get the results of a Workflow Execution {/* #get-workflow-results */} If the call to start a Workflow Execution is successful, you will gain access to the Workflow Execution's Run Id. diff --git a/docs/develop/typescript/index.mdx b/docs/develop/typescript/index.mdx index df58ab659b..d56f191890 100644 --- a/docs/develop/typescript/index.mdx +++ b/docs/develop/typescript/index.mdx @@ -97,7 +97,7 @@ Integrate the Vercel AI SDK with Temporal to build durable AI agents and AI-powe - [Temporal TypeScript Community Slack](https://temporalio.slack.com/archives/C01DKSMU94L) - [TypeScript SDK Forum](https://community.temporal.io/tag/typescript-sdk) -## Linting and types in TypeScript {#linting-and-types} +## Linting and types in TypeScript {/* #linting-and-types */} If you started your project with `@temporalio/create`, you already have our recommended TypeScript and ESLint configurations. diff --git a/docs/develop/typescript/install-typescript-sdk.mdx b/docs/develop/typescript/install-typescript-sdk.mdx index b13c7f716f..ff0b3ef555 100644 --- a/docs/develop/typescript/install-typescript-sdk.mdx +++ b/docs/develop/typescript/install-typescript-sdk.mdx @@ -9,7 +9,7 @@ tags: - Temporal SDKs --- -## How to install a Temporal SDK {#install-a-temporal-sdk} +## How to install a Temporal SDK {/* #install-a-temporal-sdk */} A [Temporal SDK](/encyclopedia/temporal-sdks) provides a framework for [Temporal Application](/temporal#temporal-application) development. @@ -45,11 +45,11 @@ JavaScript. ::: -### How to find the TypeScript SDK API reference {#api-reference} +### How to find the TypeScript SDK API reference {/* #api-reference */} The Temporal TypeScript SDK API reference is published to [typescript.temporal.io](https://typescript.temporal.io). -### Where are SDK-specific code examples? {#code-samples} +### Where are SDK-specific code examples? {/* #code-samples */} You can find a complete list of executable code samples in [Temporal's GitHub repository](https://github.com/temporalio?q=samples-&type=all&language=&sort=). @@ -64,7 +64,7 @@ various capabilities of Temporal. [Temporal TypeScript YouTube playlist](https://www.youtube.com/playlist?list=PLl9kRkvFJrlTavecydpk9r6cF7qBmQJvb). -### How to import an ECMAScript module {#ecmascript-modules} +### How to import an ECMAScript module {/* #ecmascript-modules */} The JavaScript ecosystem is quickly moving toward publishing ECMAScript modules (ESM) instead of CommonJS modules. For example, `node-fetch@3` is ESM, but `node-fetch@2` is CommonJS. @@ -77,7 +77,7 @@ changes: - `tsconfig.json` should output in `esnext` format. - Imports must include the `.js` file extension. -## Linting and types in TypeScript {#linting-and-types} +## Linting and types in TypeScript {/* #linting-and-types */} If you started your project with `@temporalio/create`, you already have our recommended TypeScript and ESLint configurations. diff --git a/docs/develop/typescript/nexus/feature-guide.mdx b/docs/develop/typescript/nexus/feature-guide.mdx index f2888532db..fab225ac12 100644 --- a/docs/develop/typescript/nexus/feature-guide.mdx +++ b/docs/develop/typescript/nexus/feature-guide.mdx @@ -44,7 +44,7 @@ This documentation uses source code derived from the [TypeScript Nexus sample](h ::: -## Run the Temporal Development Server with Nexus enabled {#run-the-temporal-nexus-development-server} +## Run the Temporal Development Server with Nexus enabled {/* #run-the-temporal-nexus-development-server */} Prerequisites: @@ -61,7 +61,7 @@ This command automatically starts the Temporal development server with the Web U The Temporal Web UI should now be accessible at [http://localhost:8233](http://localhost:8233), and the Temporal Server should now be available for client connections on `localhost:7233`. -## Create caller and handler Namespaces {#create-caller-handler-namespaces} +## Create caller and handler Namespaces {/* #create-caller-handler-namespaces */} Before setting up Nexus endpoints, create separate Namespaces for the caller and handler. @@ -73,7 +73,7 @@ temporal operator namespace create --namespace my-caller-namespace For this example, `my-target-namespace` will contain the Nexus Operation handler, and you will use a Workflow in `my-caller-namespace` to call that Operation handler. We use different namespaces to demonstrate cross-Namespace Nexus calls. -## Create a Nexus Endpoint to route requests from caller to handler {#create-nexus-endpoint} +## Create a Nexus Endpoint to route requests from caller to handler {/* #create-nexus-endpoint */} After establishing caller and handler Namespaces, the next step is to create a Nexus Endpoint to route requests. @@ -86,7 +86,7 @@ temporal operator nexus endpoint create \ You can also use the Web UI to create the Namespaces and Nexus endpoint. -## Define the Nexus Service contract {#define-nexus-service-contract} +## Define the Nexus Service contract {/* #define-nexus-service-contract */} Defining a clear contract for the Nexus Service is crucial for smooth communication. @@ -139,7 +139,7 @@ export type LanguageCode = 'en' | 'fr' | 'de' | 'es' | 'tr'; ``` -## Develop a Nexus Service handler and Operation handlers {#develop-nexus-service-operation-handlers} +## Develop a Nexus Service handler and Operation handlers {/* #develop-nexus-service-operation-handlers */} A Nexus Service handler is defined using the `nexus-rpc`'s [`serviceHandler`](https://nexus-rpc.github.io/sdk-typescript/functions/serviceHandler.html) function. {/* Added */} Nexus Service handlers are typically defined in the same Worker as the underlying Temporal primitives they abstract. @@ -295,7 +295,7 @@ import { helloServiceHandler } from './handler'; ``` -## Develop a caller Workflow that uses the Nexus Service {#develop-caller-workflow-nexus-service} +## Develop a caller Workflow that uses the Nexus Service {/* #develop-caller-workflow-nexus-service */} To execute a Nexus Operation from a Workflow, import the necessary service definition types, then use `@temporalio/workflow`'s `createNexusServiceClient` to create a Nexus client for that service. You will need to provide the Nexus Endpoint name, which you registered previously in [Create a Nexus Endpoint to route requests from caller to handler](#create-nexus-endpoint). @@ -336,7 +336,7 @@ Refer to the [complete TypeScript sample](https://github.com/temporalio/samples- - [nexus-hello/src/caller/worker.ts](https://github.com/temporalio/samples-typescript/blob/main/nexus-hello/src/caller/worker.ts) shows how to register the caller Workflow in a Worker and run the Worker. - [nexus-hello/src/starter.ts](https://github.com/temporalio/samples-typescript/blob/main/nexus-hello/src/starter.ts) shows how to use a Temporal Client to execute the sample caller Workflow. -## Exceptions in Nexus operations {#exceptions-in-nexus-operations} +## Exceptions in Nexus operations {/* #exceptions-in-nexus-operations */} Temporal provides general guidance on [Errors in Nexus operations](https://docs.temporal.io/references/failures#errors-in-nexus-operations). In TypeScript, there are three Nexus-specific exception classes: @@ -345,7 +345,7 @@ In TypeScript, there are three Nexus-specific exception classes: - `nexus-rpc`'s [`HandlerError`](https://nexus-rpc.github.io/sdk-typescript/classes/HandlerError.html): you can throw this exception type in a Nexus operation with a specific [HandlerErrorType](https://nexus-rpc.github.io/sdk-typescript/types/HandlerErrorType.html). The error will be marked as either retryable or non-retryable according to the type, following the [Nexus spec](https://github.com/nexus-rpc/api/blob/main/SPEC.md#predefined-handler-errors). The non-retryable handler error types are `BAD_REQUEST`, `UNAUTHENTICATED`, `UNAUTHORIZED`, `NOT_FOUND`, `NOT_IMPLEMENTED`; the retryable types are `RESOURCE_EXHAUSTED`, `INTERNAL`, `UNAVAILABLE`, `UPSTREAM_TIMEOUT`. - `@temporalio/nexus`'s [`NexusOperationFailure`](https://typescript.temporal.io/api/classes/common.NexusOperationFailure): this is the error thrown inside a Workflow when a Nexus operation fails for any reason. Use the `cause` attribute on the exception to access the cause chain. -## Canceling a Nexus Operation {#canceling-a-nexus-operation} +## Canceling a Nexus Operation {/* #canceling-a-nexus-operation */} Nexus Operations, just like other cancellable APIs provided by the `@temporalio/workflow` package, execute within Cancellation Scopes. Requesting cancellation of a Cancellation Scope results in requesting cancellation for all cancellable operations owned by that scope. @@ -362,7 +362,7 @@ Once the caller Workflow completes, the caller's Nexus Machinery will not make a It's okay to leave operations running in some use cases. To ensure cancellations are delivered, wait for all pending operations to finish before exiting the Workflow. -## Make Nexus calls across Namespaces in Temporal Cloud {#nexus-calls-across-namespaces-temporal-cloud} +## 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. 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. diff --git a/docs/develop/typescript/platform/observability.mdx b/docs/develop/typescript/platform/observability.mdx index ceccf8775f..ee6d4b7e26 100644 --- a/docs/develop/typescript/platform/observability.mdx +++ b/docs/develop/typescript/platform/observability.mdx @@ -25,7 +25,7 @@ This section covers features related to viewing the state of the application, in - [Log from a Workflow](#logging) - [Visibility APIs](#visibility) -## Emit metrics {#metrics} +## Emit metrics {/* #metrics */} Each Temporal SDK is capable of emitting an optional set of metrics from either the Client or the Worker process. For a complete list of metrics capable of being emitted, see the [SDK metrics reference](/references/sdk-metrics). @@ -51,7 +51,7 @@ telemetryOptions: { }, ``` -## Set up tracing {#tracing} +## Set up tracing {/* #tracing */} Tracing allows you to view the call graph of a Workflow along with its Activities and any Child Workflows. @@ -96,7 +96,7 @@ To extend the default ([Trace Context](https://github.com/open-telemetry/opentel Similarly, you can customize the OpenTelemetry `NodeSDK` propagators by following the instructions in the [Initialize the SDK](https://github.com/open-telemetry/opentelemetry-js/tree/main/experimental/packages/opentelemetry-sdk-node#initialize-the-sdk) section of the `README.md` file. -## Log from a Workflow {#logging} +## Log from a Workflow {/* #logging */} Logging enables you to record critical information during code execution. Loggers create an audit trail and capture information about your Workflow's operation. @@ -378,7 +378,7 @@ The injected sink function contributes to the overall Workflow Task processing d - If you have a long-running sink function, such as one that tries to communicate with external services, you might start seeing Workflow Task timeouts. - The effect is multiplied when using `callDuringReplay: true` and replaying long Workflow histories because the Workflow Task timer starts when the first history page is delivered to the Worker. -### How to provide a custom logger {#custom-logger} +### How to provide a custom logger {/* #custom-logger */} Use a custom logger for logging. @@ -430,11 +430,11 @@ const logger = winston.createLogger({ Runtime.install({ logger }); ``` -## Visibility APIs {#visibility} +## Visibility APIs {/* #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 Temporal Service. -### How to use Search Attributes {#search-attributes} +### How to use Search Attributes {/* #search-attributes */} The typical method of retrieving a Workflow Execution is by its Workflow Id. @@ -473,7 +473,7 @@ const response = await connection.workflowService.listWorkflowExecutions({ where `query` is a [List Filter](/list-filter). -### How to set custom Search Attributes {#custom-search-attributes} +### How to set custom Search Attributes {/* #custom-search-attributes */} After you've created custom Search Attributes in your Temporal Service (using `temporal operator search-attribute create` or the Cloud UI), you can set the values of the custom Search Attributes when starting a Workflow. @@ -502,7 +502,7 @@ const { searchAttributes } = await handle.describe(); The type of `searchAttributes` is `Record`. -### How to upsert Search Attributes {#upsert-search-attributes} +### How to upsert Search Attributes {/* #upsert-search-attributes */} You can upsert Search Attributes to add or update Search Attributes from within Workflow code. @@ -528,7 +528,7 @@ export async function example(): Promise { ``` -### How to remove a Search Attribute from a Workflow {#remove-search-attribute} +### How to remove a Search Attribute from a Workflow {/* #remove-search-attribute */} To remove a Search Attribute that was previously set, set it to an empty array: `[]`. diff --git a/docs/develop/typescript/worker-versioning-legacy.mdx b/docs/develop/typescript/worker-versioning-legacy.mdx index 5b5fac2edf..b01bee4446 100644 --- a/docs/develop/typescript/worker-versioning-legacy.mdx +++ b/docs/develop/typescript/worker-versioning-legacy.mdx @@ -12,7 +12,7 @@ tags: - TypeScript SDK --- -## How to use Worker Versioning in TypeScript (Deprecated) {#worker-versioning} +## How to use Worker Versioning in TypeScript (Deprecated) {/* #worker-versioning */} :::caution diff --git a/docs/develop/typescript/workers/interceptors.mdx b/docs/develop/typescript/workers/interceptors.mdx index 3c1d8e8351..cf333c88a1 100644 --- a/docs/develop/typescript/workers/interceptors.mdx +++ b/docs/develop/typescript/workers/interceptors.mdx @@ -25,7 +25,7 @@ There are two main types of interceptors--inbound and outbound. Those further break down into concrete Interceptor types--see below. -## How to implement interceptors in TypeScript {#interceptors} +## How to implement interceptors in TypeScript {/* #interceptors */} Interceptors run as a chain. Each interceptor wraps the entire inner call: your code runs before the call, invokes `next` to execute the rest of the chain, and then runs after the call completes. This means you can inspect or modify both the `input` and the result, handle errors, and perform side effects at either stage. @@ -108,7 +108,7 @@ export class NexusOperationLogInterceptor implements NexusInboundCallsIntercepto } ``` -## Register an Interceptor {#register-interceptor} +## Register an Interceptor {/* #register-interceptor */} Registering an interceptor means providing it to the SDK so Temporal can invoke it when matching Client or Worker calls occur. Once registered, it runs in the call path and can observe or modify request and response data. diff --git a/docs/develop/typescript/workers/run-process.mdx b/docs/develop/typescript/workers/run-process.mdx index 173a744b3a..f1272c7201 100644 --- a/docs/develop/typescript/workers/run-process.mdx +++ b/docs/develop/typescript/workers/run-process.mdx @@ -11,7 +11,7 @@ tags: - Worker --- -## How to run Worker Processes {#run-a-dev-worker} +## How to run Worker Processes {/* #run-a-dev-worker */} The [Worker Process](/workers#worker-process) is where Workflow Functions and Activity Functions are executed. @@ -29,7 +29,7 @@ perfectly sufficient. For more information, see the [Worker tuning guide](/devel A Worker Entity contains a Workflow Worker and/or an Activity Worker, which makes progress on Workflow Executions and Activity Executions, respectively. -## How to run a Worker on Docker in TypeScript {#run-a-worker-on-docker} +## How to run a Worker on Docker in TypeScript {/* #run-a-worker-on-docker */} :::note @@ -154,7 +154,7 @@ Or like this: Error: Error relocating /opt/app/node_modules/@temporalio/core-bridge/index.node: __register_atfork: symbol not found ``` -## How to run a Temporal Cloud Worker {#run-a-temporal-cloud-worker} +## How to run a Temporal Cloud Worker {/* #run-a-temporal-cloud-worker */} To run a Worker that uses [Temporal Cloud](/cloud), you need to provide additional connection and client options that include the following: @@ -170,7 +170,7 @@ For more information about managing and generating client certificates for Tempo For more information about configuring TLS to secure inter- and intra-network communication for a Temporal Service, see [Temporal Customization Samples](https://github.com/temporalio/samples-server). -### How to register types {#register-types} +### How to register types {/* #register-types */} All Workers listening to the same Task Queue name must be registered to handle the exact same Workflows Types and Activity Types. @@ -249,7 +249,7 @@ async function run() { ``` -## How to shut down a Worker and track its state {#shut-down-a-worker} +## How to shut down a Worker and track its state {/* #shut-down-a-worker */} Workers shut down if they receive any of the Signals enumerated in [shutdownSignals](https://typescript.temporal.io/api/interfaces/worker.RuntimeOptions#shutdownsignals): `'SIGINT'`, diff --git a/docs/develop/typescript/workers/serverless-workers/aws-lambda.mdx b/docs/develop/typescript/workers/serverless-workers/aws-lambda.mdx index dcf930d582..cff408b608 100644 --- a/docs/develop/typescript/workers/serverless-workers/aws-lambda.mdx +++ b/docs/develop/typescript/workers/serverless-workers/aws-lambda.mdx @@ -35,7 +35,7 @@ You register Workflows and Activities the same way you would with a standard Wor For a full end-to-end deployment guide covering AWS IAM setup, compute configuration, and verification, see [Deploy a Serverless Worker on AWS Lambda](/production-deployment/worker-deployments/serverless-workers/aws-lambda). -## Create and run a Worker in Lambda {#create-and-run} +## Create and run a Worker in Lambda {/* #create-and-run */} Use the `runWorker` function to create a Lambda handler that runs a Temporal Worker. Pass a deployment version and a configure callback that sets up your Workflows and Activities. @@ -64,7 +64,7 @@ Worker Deployment Versioning is always enabled for Serverless Workers. Each Workflow must declare a [versioning behavior](/worker-versioning#versioning-behaviors), either `AutoUpgrade` or `Pinned`. The default versioning behavior is `PINNED`. To change it, set `workerDeploymentOptions.defaultVersioningBehavior` in the configure callback. -### Pre-bundle Workflow code {#pre-bundle} +### Pre-bundle Workflow code {/* #pre-bundle */} Use `workflowBundle` with pre-bundled code instead of `workflowsPath`. Pre-bundling avoids webpack bundling overhead on every Lambda cold start. @@ -83,7 +83,7 @@ await writeFile('./workflow-bundle.js', code); Then reference the bundle in your handler with `workflowBundle: { codePath: require.resolve('./workflow-bundle.js') }`. -## Configure the Temporal connection {#configure-connection} +## Configure the Temporal connection {/* #configure-connection */} The `@temporalio/lambda-worker` package automatically loads Temporal client configuration from a TOML config file and environment variables. Refer to [Environment Configuration](/develop/environment-configuration) for more details. @@ -97,7 +97,7 @@ The file is optional. If absent, only environment variables are used. Encrypt sensitive values like TLS keys or API keys. Refer to [AWS documentation](https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars-encryption.html) for options. -## Adjust Worker defaults for Lambda {#lambda-tuned-defaults} +## Adjust Worker defaults for Lambda {/* #lambda-tuned-defaults */} The `@temporalio/lambda-worker` package applies conservative defaults suited to short-lived Lambda invocations. These differ from standard Worker defaults to avoid overcommitting resources in a constrained environment. @@ -124,7 +124,7 @@ The default is `shutdownGraceTime` (5s) + 2s. If your Worker handles long-running Activities, increase `shutdownGraceTime`, `shutdownDeadlineBufferMs`, and the Lambda invocation deadline (`--timeout`) together. For guidance on how these values relate, see [Tuning for long-running Activities](/serverless-workers#tuning-for-long-running-activities). -## Add observability with OpenTelemetry {#add-observability} +## Add observability with OpenTelemetry {/* #add-observability */} The `@temporalio/lambda-worker/otel` module provides OpenTelemetry integration with defaults configured for the [AWS Distro for OpenTelemetry (ADOT)](https://aws-otel.github.io/docs/getting-started/lambda) Lambda layers. With this enabled, the Worker emits SDK metrics and distributed traces for Workflow and Activity executions. diff --git a/docs/develop/typescript/workflows/basics.mdx b/docs/develop/typescript/workflows/basics.mdx index 7e2cd0354e..705c5d096f 100644 --- a/docs/develop/typescript/workflows/basics.mdx +++ b/docs/develop/typescript/workflows/basics.mdx @@ -11,7 +11,7 @@ tags: - Workflow --- -## How to develop a Workflow {#develop-workflows} +## How to develop a 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 @@ export async function example(args: ExampleArgs): Promise<{ greeting: string }> } ``` -## How to define Workflow parameters {#workflow-parameters} +## How to 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 +71,7 @@ export async function example({ name, born }: ExampleParam): Promise { } ``` -## How to define Workflow return parameters {#workflow-return-values} +## How to define Workflow return parameters {/* #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 +92,7 @@ export async function example({ name, born }: ExampleParam): Promise { } ``` -## How to customize your Workflow Type {#workflow-type} +## How to customize your Workflow Type {/* #workflow-type */} Workflows have a Type that are referred to as the Workflow name. @@ -112,7 +112,7 @@ export async function helloWorld(): Promise { ``` -## How to develop Workflow logic {#workflow-logic-requirements} +## How to develop Workflow logic {/* #workflow-logic-requirements */} Workflow logic is constrained by [deterministic execution requirements](/workflow-definition#deterministic-constraints). Each Temporal SDK provides a diff --git a/docs/develop/typescript/workflows/cancellation-scopes.mdx b/docs/develop/typescript/workflows/cancellation-scopes.mdx index aa1401bdcb..6181faab6d 100644 --- a/docs/develop/typescript/workflows/cancellation-scopes.mdx +++ b/docs/develop/typescript/workflows/cancellation-scopes.mdx @@ -11,7 +11,7 @@ tags: - Workflow --- -## Cancellation scopes in Typescript {#cancellation-scopes} +## Cancellation scopes in Typescript {/* #cancellation-scopes */} In the TypeScript SDK, Workflows are represented internally by a tree of cancellation scopes, each with cancellation behaviors you can specify. By default, everything runs in the "root" scope. diff --git a/docs/develop/typescript/workflows/cancellation.mdx b/docs/develop/typescript/workflows/cancellation.mdx index 2001128eb6..7606f4f363 100644 --- a/docs/develop/typescript/workflows/cancellation.mdx +++ b/docs/develop/typescript/workflows/cancellation.mdx @@ -14,7 +14,7 @@ description: within Temporal Workflows with ease. --- -## Cancel an Activity from a Workflow {#cancel-an-activity} +## Cancel an Activity from a Workflow {/* #cancel-an-activity */} Canceling an Activity from within a Workflow requires that the Activity Execution sends Heartbeats and sets a Heartbeat Timeout. If the Heartbeat is not invoked, the Activity cannot receive a cancellation request. When any non-immediate @@ -34,7 +34,7 @@ Worker process. ::: -## Reset a Workflow Execution {#reset} +## Reset a Workflow Execution {/* #reset */} Resetting a Workflow Execution terminates the current Workflow Execution and starts a new Workflow Execution from a point you specify in its Event History. Use reset when a Workflow is blocked due to a non-deterministic error or other diff --git a/docs/develop/typescript/workflows/child-workflows.mdx b/docs/develop/typescript/workflows/child-workflows.mdx index 5ea31f9b44..2b40eab07b 100644 --- a/docs/develop/typescript/workflows/child-workflows.mdx +++ b/docs/develop/typescript/workflows/child-workflows.mdx @@ -14,7 +14,7 @@ tags: description: Start and manage Child Workflow Executions using Temporal's Child Workflow API, including setting Parent Close Policy, handling Events, and advanced Child Workflow options. --- -## How to start a Child Workflow Execution {#child-workflows} +## How to start a Child Workflow Execution {/* #child-workflows */} A [Child Workflow Execution](/child-workflows) is a Workflow Execution that is scheduled from within another Workflow using a Child Workflow API. @@ -91,7 +91,7 @@ Two advanced options are unique to Child Workflows: If you need to cancel a Child Workflow Execution, use [cancellation scopes](/develop/typescript/workflows/cancellation-scopes). A Child Workflow Execution is automatically cancelled when its containing scope is cancelled. -### How to set a Parent Close Policy {#parent-close-policy} +### How to set a Parent Close Policy {/* #parent-close-policy */} A [Parent Close Policy](/parent-close-policy) determines what happens to a Child Workflow Execution if its Parent changes to a Closed status (Completed, Failed, or Timed Out). diff --git a/docs/develop/typescript/workflows/continue-as-new.mdx b/docs/develop/typescript/workflows/continue-as-new.mdx index 380b514e12..cfe839dd25 100644 --- a/docs/develop/typescript/workflows/continue-as-new.mdx +++ b/docs/develop/typescript/workflows/continue-as-new.mdx @@ -24,7 +24,7 @@ This page answers the following questions for Typescript developers: - [When is it right to Continue-as-New?](#when) - [How to test Continue-as-New?](#how-to-test) -## What is Continue-As-New? {#what} +## What is Continue-As-New? {/* #what */} [Continue-As-New](/workflow-execution/continue-as-new) lets a Workflow Execution close successfully and creates a new Workflow Execution. You can think of it as a checkpoint when your Workflow gets too long or approaches certain scaling limits. @@ -32,7 +32,7 @@ You can think of it as a checkpoint when your Workflow gets too long or approach The new Workflow Execution is in the same [chain](/workflow-execution#workflow-execution-chain); it keeps the same Workflow Id but gets a new Run Id and a fresh Event History. It also receives your Workflow's usual parameters. -## How to Continue-As-New using the Typescript SDK {#how} +## How to Continue-As-New using the Typescript SDK {/* #how */} First, design your Workflow parameters so that you can pass in the "current state" when you Continue-As-New into the next Workflow run. This state is typically set to `None` for the original caller of the Workflow. @@ -69,20 +69,20 @@ return await wf.continueAsNew({ }); ```` -### Considerations for Workflows with Message Handlers {#with-message-handlers} +### Considerations for Workflows with Message Handlers {/* #with-message-handlers */} If you use Updates or Signals, don't call Continue-as-New from the handlers. Instead, wait for your handlers to finish in your main Workflow before you run `ContinueAsNew`. See the [`allHandlersFinished`](message-passing#wait-for-message-handlers) example for guidance. -## When is it right to Continue-as-New using the Typescript SDK? {#when} +## When is it right to Continue-as-New using the Typescript SDK? {/* #when */} Use Continue-as-New when your Workflow might hit [Event History Limits](/workflow-execution/event#event-history). Temporal tracks your Workflow's progress against these limits to let you know when you should Continue-as-New. Call `wf.workflowInfo().continueAsNewSuggested` to check if it's time. -## How to test Continue-as-New using the Typescript SDK {#how-to-test} +## How to test Continue-as-New using the Typescript SDK {/* #how-to-test */} Testing Workflows that naturally Continue-as-New may be time-consuming and resource-intensive. Instead, add a test hook to check your Workflow's Continue-as-New behavior faster in automated tests. diff --git a/docs/develop/typescript/workflows/message-passing.mdx b/docs/develop/typescript/workflows/message-passing.mdx index d71309141f..8db04c68ce 100644 --- a/docs/develop/typescript/workflows/message-passing.mdx +++ b/docs/develop/typescript/workflows/message-passing.mdx @@ -32,7 +32,7 @@ Temporal Clients use messages to read Workflow state and control its execution. See [Workflow message passing](/encyclopedia/workflow-message-passing) for a general overview of this topic. This page introduces these features for the Temporal Typescript SDK. -## Write message handlers {#writing-message-handlers} +## Write message handlers {/* #writing-message-handlers */} :::info The code that follows is part of a working [message-passing sample](https://github.com/temporalio/samples-typescript/tree/main/message-passing/introduction). @@ -47,7 +47,7 @@ Follow these guidelines when writing your message handlers: - Prefer using a single object over multiple input parameters. A single object allows you to add fields without changing the signature. -### Query handlers {#queries} +### Query handlers {/* #queries */} A [Query](/sending-messages#sending-queries) is a synchronous operation that retrieves state from a Workflow Execution: @@ -95,7 +95,7 @@ export async function greetingWorkflow(): Promise { - `setHandler` can take `QueryHandlerOptions` (such as `description`) as described in the API reference docs for [`workflow.setHandler`](https://typescript.temporal.io/api/namespaces/workflow#sethandler). -### Signal handlers {#signals} +### Signal handlers {/* #signals */} A [Signal](/sending-messages#sending-signals) is an asynchronous message sent to a running Workflow Execution to change its state and control its flow: @@ -130,7 +130,7 @@ export async function greetingWorkflow(): Promise { - `setHandler` can take `SignalHandlerOptions` (such as `description` and `unfinishedPolicy`) as described in the API reference docs for [`workflow.setHandler`](https://typescript.temporal.io/api/namespaces/workflow#sethandler). -### Update handlers and validators {#updates} +### Update handlers and validators {/* #updates */} An [Update](/sending-messages#sending-updates) is a trackable synchronous request sent to a running Workflow Execution. It can change the Workflow state, control its flow, and return a result. @@ -195,7 +195,7 @@ wf.setHandler( See [Async handlers](#async-handlers) and [Workflow message passing](/encyclopedia/workflow-message-passing) for safe usage guidelines. - If your Workflow needs to do some async initialization before handling an Update or Signal, use [`workflow.condition`](https://typescript.temporal.io/api/namespaces/workflow#condition) inside your handler to wait until initialization has completed. -## Send messages {#send-messages} +## Send messages {/* #send-messages */} To send Queries, Signals, or Updates, you call methods on a [WorkflowHandle](https://typescript.temporal.io/api/namespaces/client#workflowhandle) object: @@ -223,7 +223,7 @@ To check the argument types required when sending messages -- and the return typ ::: -### Send a Query {#send-query} +### Send a Query {/* #send-query */} Use [`WorkflowHandle.query`](https://typescript.temporal.io/api/interfaces/client.WorkflowHandle/#query) to send a Query to a Workflow Execution: @@ -241,12 +241,12 @@ const supportedLanguages = await handle.query(getLanguages, { - A Worker must be online and polling the Task Queue to process a Query. -### Send a Signal {#send-signal} +### Send a Signal {/* #send-signal */} You can send a Signal to a Workflow Execution from a Temporal Client or from another Workflow Execution. However, you can only send Signals to Workflow Executions that haven’t closed. -#### Send a Signal from a Client {#send-signal-from-client} +#### Send a Signal from a Client {/* #send-signal-from-client */} Use [WorkflowHandle.signal](https://typescript.temporal.io/api/interfaces/client.WorkflowHandle#signal) to send a Signal: @@ -258,7 +258,7 @@ await handle.signal(greetingWorkflow.approve, { name: 'me' }); - The [WorkflowExecutionSignaled](/references/events#workflowexecutionsignaled) Event appears in the Workflow's Event History. -### Send a Signal from a Workflow {#send-signal-from-workflow} +### Send a Signal from a Workflow {/* #send-signal-from-workflow */} A Workflow can send a Signal to another Workflow, in which case it's called an _External Signal_. Use [`getExternalWorkflowHandle`](https://typescript.temporal.io/api/namespaces/workflow#getExternalWorkflowHandle): @@ -283,7 +283,7 @@ Recall that one aspect of deterministic Workflows means not directly making netw This means that developers cannot use a Temporal Client directly within the Workflow code to send Signals or start other Workflows. Instead, to communicate between Workflows, we use `getExternalWorkflowHandle` to both ensure that Workflows remain deterministic and also that these interactions are recorded as Events in the Workflow's Event History. -### Signal-With-Start {#signal-with-start} +### Signal-With-Start {/* #signal-with-start */} Signal-With-Start allows a Client to send a Signal to a Workflow Execution, starting the Execution if it is not already running. Use [`Client.workflow.signalWithStart`](https://typescript.temporal.io/api/classes/client.WorkflowClient#signalwithstart): @@ -306,7 +306,7 @@ await client.workflow.signalWithStart(yourWorkflow, { Signal-With-Start is limited to Client use. It cannot be called from a Workflow. -### Send an Update {#send-update-from-client} +### Send an Update {/* #send-update-from-client */} An Update is a synchronous, blocking call that can change Workflow state, control its flow, and return a result. @@ -352,7 +352,7 @@ To obtain an Update handle, you can: - Use [`WorkflowHandle.startUpdate`](https://typescript.temporal.io/api/interfaces/client.WorkflowHandle/#startUpdate) to start an Update and return the handle, as shown in the preceding example. - Use [`getUpdateHandle`](https://typescript.temporal.io/api/interfaces/client.WorkflowHandle/#getupdatehandle) to fetch a handle for an in-progress Update using the Update ID. -#### Update-With-Start {#update-with-start} +#### Update-With-Start {/* #update-with-start */} :::tip @@ -419,7 +419,7 @@ Pass Workflow IDs to these APIs to get Workflow handles: ::: -## Message handler patterns {#message-handler-patterns} +## Message handler patterns {/* #message-handler-patterns */} This section covers common write operations, such as Signal and Update handlers. It doesn't apply to pure read operations, like Queries or Update Validators. @@ -430,7 +430,7 @@ For additional information, see [Inject work into the main Workflow](/handling-m ::: -### Use async handlers {#async-handlers} +### Use async handlers {/* #async-handlers */} Signal and Update handlers can be `async` functions. Using `async` allows you to use `await` with Activities, Child Workflows, durable [`workflow.sleep`](https://typescript.temporal.io/api/namespaces/workflow#sleep) Timers, [`workflow.condition`](https://typescript.temporal.io/api/namespaces/workflow#condition) conditions, etc. @@ -539,7 +539,7 @@ Remember: handlers can execute before the main Workflow method starts. You can also use wait conditions anywhere else in the handler to wait for a specific condition to become true. This allows you to write handlers that pause at multiple points, each time waiting for a required condition to become true. -#### Ensure your handlers finish before the Workflow completes {#wait-for-message-handlers} +#### Ensure your handlers finish before the Workflow completes {/* #wait-for-message-handlers */} Workflow wait conditions can ensure your handler completes before a Workflow finishes. When your Workflow uses `async` Signal or Update handlers, your main Workflow method can return or Continue-as-New while a handler is still waiting on an async task, such as an Activity result. @@ -558,7 +558,7 @@ You can silence these warnings on a per-handler basis by setting the `unfinished See [Finishing handlers before the Workflow completes](/handling-messages#finishing-message-handlers) for more information. -### Use a lock to prevent concurrent handler execution {#control-handler-concurrency} +### Use a lock to prevent concurrent handler execution {/* #control-handler-concurrency */} Concurrent processes can interact in unpredictable ways. Incorrectly written [concurrent message-passing](/handling-messages#message-handler-concurrency) code may not work correctly when multiple handler instances run simultaneously. @@ -615,7 +615,7 @@ export async function myWorkflow(): Promise { } ``` -## Message handler troubleshooting {#message-handler-troubleshooting} +## Message handler troubleshooting {/* #message-handler-troubleshooting */} When sending a Signal, Update, or Query to a Workflow, your Client might encounter the following errors: @@ -625,13 +625,13 @@ When sending a Signal, Update, or Query to a Workflow, your Client might encount - **The workflow does not exist**: You'll receive an [`common.WorkflowNotFoundError`](https://typescript.temporal.io/api/classes/common.WorkflowNotFoundError) error. -### Problems when sending a Signal {#signal-problems} +### Problems when sending a Signal {/* #signal-problems */} When using Signal, the two errors described above are the only errors that will result from your requests. For Queries and Updates, the client waits for a response from the Worker and therefore additional errors may occur during the handler Execution by the Worker. -### Problems when sending an Update {#update-problems} +### Problems when sending an Update {/* #update-problems */} When working with Updates, you may encounter these problems: @@ -667,7 +667,7 @@ When working with Updates, you may encounter these problems: - The Workflow completed normally or continued-as-new and the Workflow author did not [wait for handlers to be finished](/handling-messages#finishing-message-handlers). -### Problems when sending a Query {#query-problems} +### Problems when sending a Query {/* #query-problems */} When working with Queries, you may encounter these errors: @@ -682,7 +682,7 @@ When working with Queries, you may encounter these errors: - **The handler caused the Workflow Task to fail.** This would happen, for example, if the Query handler blocks the thread for too long without yielding. -## Define Signals and Queries statically or dynamically {#dynamic-handler} +## Define Signals and Queries statically or dynamically {/* #dynamic-handler */} - Handlers for both Signals and Queries can take arguments, which can be used inside `setHandler` logic. - Only Signal Handlers can mutate state, and only Query Handlers can return values. @@ -690,7 +690,7 @@ When working with Queries, you may encounter these errors: * [Define Signals and Queries statically](#static-signals-and-queries) * [Define Signals and Queries dynamically](#dynamic-signals-and-queries) -### Define Signals and Queries statically {#static-signals-and-queries} +### Define Signals and Queries statically {/* #static-signals-and-queries */} If you know the name of your Signals and Queries upfront, we recommend declaring them outside the Workflow Definition. @@ -722,7 +722,7 @@ export async function unblockOrCancel(): Promise { This technique helps provide type safety because you can export the type signature of the Signal or Query to be called by the Client. -### Define Signals and Queries dynamically {#dynamic-signals-and-queries} +### Define Signals and Queries dynamically {/* #dynamic-signals-and-queries */} For more flexible use cases, you might want a dynamic Signal (such as a generated ID). You can handle it in two ways: diff --git a/docs/develop/typescript/workflows/schedules.mdx b/docs/develop/typescript/workflows/schedules.mdx index 53a059537f..e3bac68592 100644 --- a/docs/develop/typescript/workflows/schedules.mdx +++ b/docs/develop/typescript/workflows/schedules.mdx @@ -28,13 +28,13 @@ This page shows how to do the following: - [Temporal Cron Jobs](#temporal-cron-jobs) - [Start Delay](#start-delay) -## How to Schedule a Workflow {#schedule-a-workflow} +## How to Schedule a Workflow {/* #schedule-a-workflow */} 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 actions to help Schedule a Workflow Execution and take control over your automation process. -### Create a Schedule {#create-schedule} +### Create a Schedule {/* #create-schedule */} The create action enables you to create a new Schedule. When you create a new Schedule, a unique Schedule ID is generated, which you can use to reference the Schedule in other Schedule commands. @@ -92,7 +92,7 @@ async function run() { ``` -### Backfill a Schedule {#backfill-schedule} +### Backfill a Schedule {/* #backfill-schedule */} The backfill action executes Actions ahead of their specified time range. This command is useful when you need to execute a missed or delayed Action, or when you want to test the Workflow before its scheduled time. @@ -123,7 +123,7 @@ async function run() { ``` -### Delete a Schedule {#delete-schedule} +### Delete a Schedule {/* #delete-schedule */} The delete action enables you to delete a Schedule. When you delete a Schedule, it does not affect any Workflows that were started by the Schedule. @@ -143,7 +143,7 @@ async function run() { ``` -### Describe a Schedule {#describe-schedule} +### Describe a Schedule {/* #describe-schedule */} The describe action shows the current Schedule configuration, including information about past, current, and future Workflow Runs. This command is helpful when you want to get a detailed view of the Schedule and its associated Workflow Runs. @@ -164,7 +164,7 @@ async function run() { ``` -### List a Schedule {#list-schedule} +### List a Schedule {/* #list-schedule */} The list action lists all the available Schedules. This command is useful when you want to view a list of all the Schedules and their respective Schedule IDs. @@ -189,7 +189,7 @@ async function run() { ``` -### Pause a Schedule {#pause-schedule} +### Pause a Schedule {/* #pause-schedule */} The pause action enables you to pause and unpause a Schedule. When you pause a Schedule, all the future Workflow Runs associated with the Schedule are temporarily stopped. This command is useful when you want to temporarily halt a Workflow due to maintenance or any other reason. @@ -209,7 +209,7 @@ async function run() { ``` -### Trigger a Schedule {#trigger-schedule} +### Trigger a Schedule {/* #trigger-schedule */} The trigger action triggers an immediate action with a given Schedule. By default, this action is subject to the Overlap Policy of the Schedule. This command is helpful when you want to execute a Workflow outside of its scheduled time. @@ -230,7 +230,7 @@ async function run() { ``` -### Update a Schedule {#update-schedule} +### Update a Schedule {/* #update-schedule */} The update action enables you to update an existing Schedule. This command is useful when you need to modify the Schedule's configuration, such as changing the start time, end time, or interval. @@ -261,7 +261,7 @@ async function run() { ``` -## Temporal Cron Jobs {#temporal-cron-jobs} +## Temporal Cron Jobs {/* #temporal-cron-jobs */} :::caution Cron support is not recommended @@ -295,7 +295,7 @@ Temporal Workflow Schedule Cron strings follow this format: * * * * * ``` -## Start Delay {#start-delay} +## Start Delay {/* #start-delay */} **How to use Start Delay** diff --git a/docs/develop/typescript/workflows/timeouts.mdx b/docs/develop/typescript/workflows/timeouts.mdx index 0825345b8d..8a56154fbc 100644 --- a/docs/develop/typescript/workflows/timeouts.mdx +++ b/docs/develop/typescript/workflows/timeouts.mdx @@ -24,7 +24,7 @@ This page shows how to do the following: - [Workflow Timeouts](#workflow-timeouts) - [Workflow retries](#workflow-retries) -## Raise and Handle Exceptions {#exception-handling} +## Raise and Handle Exceptions {/* #exception-handling */} In each Temporal SDK, error handling is implemented idiomatically, following the conventions of the language. Temporal uses several different error classes internally — for example, [`CancelledFailure`](https://typescript.temporal.io/api/classes/common.CancelledFailure) in the Typescript SDK, to handle a Workflow cancellation. @@ -75,7 +75,7 @@ if (chargeAmount < 0) { You can alternately specify a list of errors that are non-retryable in your Activity [Retry Policy](/develop/typescript/activities/timeouts#activity-retries). -## Failing Workflows {#workflow-failure} +## Failing Workflows {/* #workflow-failure */} One of the core design principles of Temporal is that an Activity Failure will never directly cause a Workflow Failure — a Workflow should never return as Failed unless deliberately. The default retry policy associated with Temporal Activities is to retry them until reaching a certain timeout threshold. @@ -103,7 +103,7 @@ In a Workflow, any exceptions that are raised other than an explicit Temporal `A This includes any typical Typescript runtime errors like an `undefined` error that are raised automatically. These errors are treated as bugs that can be corrected with a fixed deployment, rather than a reason for a Temporal Workflow Execution to return unexpectedly. -## Workflow Timeouts {#workflow-timeouts} +## Workflow Timeouts {/* #workflow-timeouts */} **How to set Workflow Timeouts using the Temporal TypeScript SDK** @@ -136,7 +136,7 @@ await client.workflow.start(example, { }); ``` -## Workflow retries {#workflow-retries} +## Workflow retries {/* #workflow-retries */} **How to set Workflow retries using the Temporal TypeScript SDK** diff --git a/docs/develop/typescript/workflows/timers.mdx b/docs/develop/typescript/workflows/timers.mdx index 68f6419d7a..01035a2ba8 100644 --- a/docs/develop/typescript/workflows/timers.mdx +++ b/docs/develop/typescript/workflows/timers.mdx @@ -14,7 +14,7 @@ tags: description: A Workflow sets durable Timers for fixed periods using sleep() or timer(). Timers are persisted, ensuring execution continues after downtime, using minimal resources. --- -## What is a Timer? {#timers} +## What is a Timer? {/* #timers */} A Workflow can set a durable Timer for a fixed time period. In some SDKs, the function is called `sleep()`, and in others, it's called `timer()`. @@ -24,7 +24,7 @@ Timers are persisted, so even if your Worker or Temporal Service is down when th Sleeping is a resource-light operation: it does not tie up the process, and you can run millions of Timers off a single Worker. -## Asynchronous design patterns in TypeScript {#asynchronous-design-patterns} +## Asynchronous design patterns in TypeScript {/* #asynchronous-design-patterns */} The real value of `sleep` and `condition` is in knowing how to use them to model asynchronous business logic. Here are some examples we use the most; we welcome more if you can think of them! diff --git a/docs/develop/typescript/workflows/versioning.mdx b/docs/develop/typescript/workflows/versioning.mdx index 1748bd71a9..4741ab3268 100644 --- a/docs/develop/typescript/workflows/versioning.mdx +++ b/docs/develop/typescript/workflows/versioning.mdx @@ -37,7 +37,7 @@ There are two primary Versioning methods that you can use: Support for the experimental Worker Versioning method before 2025 will be removed from Temporal Server in March 2026. Refer to the [latest Worker Versioning docs](/worker-versioning) for guidance. You can still refer to the [Worker Versioning Legacy](/develop/typescript/worker-versioning-legacy) docs if needed. ::: -## Versioning with Patching {#patching} +## Versioning with Patching {/* #patching */} ### Adding a patch @@ -97,7 +97,7 @@ export async function myWorkflow(): Promise { } ``` -### Deprecating patches {#deprecated-patches} +### Deprecating patches {/* #deprecated-patches */} After ensuring that all Workflows started with `v1` code have left retention, you can [deprecate the patch](https://typescript.temporal.io/api/namespaces/workflow#deprecatepatch). @@ -116,7 +116,7 @@ export async function myWorkflow(): Promise { } ``` -### Removing a patch {#deploy-new-code} +### Removing a patch {/* #deploy-new-code */} Once your pre-patch Workflows have left retention, you can then safely deploy Workers that no longer use either the `patched()` or `deprecatePatch()` calls: diff --git a/docs/develop/worker-performance.mdx b/docs/develop/worker-performance.mdx index 361bebff48..4423a8ed7c 100644 --- a/docs/develop/worker-performance.mdx +++ b/docs/develop/worker-performance.mdx @@ -25,11 +25,11 @@ The omitted prefix makes the names more readable and descriptive. ::: -## Worker performance concepts {#worker-performance-concepts} +## Worker performance concepts {/* #worker-performance-concepts */} A Worker's performance characteristics are affected by, but not limited to, the following elements. -### Task slots {#slots} +### Task slots {/* #slots */} A **Worker Task Slot**, represents the capacity of a Temporal Worker to execute a single concurrent Task. Slots are crucial for managing the workload and performance of Workers in a Temporal application. @@ -37,7 +37,7 @@ They're used for both Workflow and Activity Tasks. When a Worker starts processing a Task, it occupies one slot. The number of available slots directly affects how many tasks a Worker can handle simultaneously. -### Slot suppliers {#slot-suppliers} +### Slot suppliers {/* #slot-suppliers */} A **Slot Supplier** defines a strategy to provide slots for a Worker, increasing or decreasing the Worker's slot count. The supplier determines when it's acceptable to begin a new Task. @@ -86,7 +86,7 @@ When running in a containerized environment, all SDKs use cgroups for both CPU a ::: -### Worker tuning {#worker-tuning} +### Worker tuning {/* #worker-tuning */} Worker tuning is the process of defining customized slot suppliers for the different task slots of a Worker to fine-tune its performance. You use special types called **Worker tuners** that assign slot suppliers to various Task Types, including Worker, Activity, Nexus, and Local Activity Tasks. @@ -176,7 +176,7 @@ The above figure shows Eager Workflow Start in action: To recover from errors, Eager Workflow Start falls back to the non-eager path. For example, when the first Task is returned eagerly, but the local Worker fails or times out while processing the task, the server retries this task non-eagerly after WorkflowTaskTimeout. -## Visualize Workers in the UI {#visualize-workers} +## Visualize Workers in the UI {/* #visualize-workers */} The Temporal SDK includes a heartbeat for Worker processes that is sent to the Server, carrying information such as available task slots, CPU usage, and Worker configuration. The Server exposes this data through APIs that surface Worker details in the Temporal UI. See a list of all running Workers by selecting Workers in the left navigation menu. @@ -185,7 +185,7 @@ View the list of Workers assigned to the Workflow Task Queue and inspect Worker This feature requires Temporal Server 1.30 or higher with API version 1.62 or higher, and is also available in Temporal Cloud. Worker Heartbeating is required; see [Manage Worker Heartbeating](/cloud/worker-health#manage-worker-heartbeating) for the minimum SDK versions. -## Performance metrics for tuning {#metrics} +## Performance metrics for tuning {/* #metrics */} The Temporal SDKs emit metrics from Temporal Client usage and Worker Processes. Performance tuning uses three important SDK metric groups: @@ -212,7 +212,7 @@ For more information about `schedule_to_start` timeout and latency, see [Schedul The [`sticky_cache_size`](/references/sdk-metrics#sticky_cache_size) and [`workflow_active_thread_count`](/references/sdk-metrics#workflow_active_thread_count) metrics report the size of the Workflow cache and the number of cached Workflow threads. -## Worker performance options {#configuration} +## Worker performance options {/* #configuration */} Each Worker can be configured by providing custom Worker options (`WorkerOptions`) at instantiation. Options are specific to individual Workers and do not affect other members of your fleet. @@ -346,7 +346,7 @@ worker = Temporalio::Worker.new( -### Cache options (Java SDK) {#cache-options} +### Cache options (Java SDK) {/* #cache-options */} A Workflow Cache is created and shared between all Workers on a single host. It's designed to limit the resources used by the cache for each host/process. @@ -368,7 +368,7 @@ There are drawbacks when you use "large values everywhere." As with any multithreading system, specifying excessively large values without monitoring with the SDK and system metrics leads to constant resource contention/stealing This decreases the total throughput and increases latency jitter of the system. -### Invariants (JavaSDK only) {#invariants} +### Invariants (JavaSDK only) {/* #invariants */} These properties should always be true for a Worker's configuration. @@ -378,14 +378,14 @@ Perform this sanity check after the adjustments to Worker settings. 2. `maxConcurrentWorkflowTaskExecutionSize` should be ≤ `maxWorkflowThreadCount`. Having more Worker slots than the Workflow cache size will lead to resource contention/stealing between executors and unpredictable delays. It's recommended that `maxWorkflowThreadCount` be at least 2x of `maxConcurrentWorkflowTaskExecutionSize`. 3. `maxConcurrentWorkflowTaskPollers` should be significantly ≤ `maxConcurrentWorkflowTaskExecutionSize`. And `maxConcurrentActivityTaskPollers` should be significantly ≤ `maxConcurrentActivityExecutionSize`. The number of pollers should always be lower than the number of executors. -## Worker runtime performance tuning {#worker-performance-tuning} +## Worker runtime performance tuning {/* #worker-performance-tuning */} Worker tuning manages the assignment of slot suppliers. A **Worker Tuner** instance exists per-Worker, providing slot suppliers for different slot types (Activity, Workflow, Nexus, or Local Activity Tasks). A tuner assigns different suppliers to each slot type. For example, it might provide a fixed assignment slot supplier for Workflows and use a resource-based supplier for Activities. -### Choosing slot supplier types {#choosing-slot-supplier-types} +### Choosing slot supplier types {/* #choosing-slot-supplier-types */} Temporal offers three types of slot suppliers: fixed assignment, resource-based, and custom. **For most workloads, Temporal recommends fixed-size slot suppliers.** @@ -413,7 +413,7 @@ Scenarios with tasks that have variable, or very high, per-task resource needs s For the highest level of control over slot allocation, consider custom slot suppliers. Custom suppliers let you tailor the logic of how slots are allocated based on your system requirements, providing flexibility to optimize for specific use cases that fixed assignment and resource-based suppliers do not fully address. -### Implement Custom Slot Suppliers {#custom-slot-implementation} +### Implement Custom Slot Suppliers {/* #custom-slot-implementation */} Implement your own Slot Supplier to control how Workers are allocated Tasks and manage the processing of Workflows, Activities, and Nexus Operations. Custom Slot Suppliers let you fine-tune task processing based on your application's needs. @@ -463,7 +463,7 @@ If a just-started worker were to have no throttle, and there was a backlog of Ta If each Task allocated 1GB of RAM, the Worker would likely run out of memory and crash. The throttle enforces a wait before handing out new slots (after a minimum number of slots have been occupied) so you can measure newly consumed resources. -## Performance tuning examples {#examples} +## Performance tuning examples {/* #examples */} The following examples show how to create and provision composite Worker tuners and set other performance related options. @@ -690,7 +690,7 @@ The `maxWorkflowThreadCount` and `workflow_active_thread_count` parameters are f ::: -## Available Task Queue information {#task-queue-metrics} +## Available Task Queue information {/* #task-queue-metrics */} :::tip Support, stability, and dependency info @@ -706,7 +706,7 @@ Available data include: - [`TasksAddRate`](#TasksAddRate-and-TasksDispatchRate) and [`TasksDispatchRate`](#TasksAddRate-and-TasksDispatchRate) - [`BacklogIncreaseRate`](#BacklogIncreaseRate) (derived from [`TasksAddRate`](#TasksAddRate-and-TasksDispatchRate) and [`TasksDispatchRate`](#TasksAddRate-and-TasksDispatchRate)) -### `ApproximateBacklogCount` and `ApproximateBacklogAge` {#ApproximateBacklogCountAndAge} +### `ApproximateBacklogCount` and `ApproximateBacklogAge` {/* #ApproximateBacklogCountAndAge */} `ApproximateBacklogCount` represents the approximate count of Tasks currently backlogged in this Task Queue. The number may include expired Tasks as well as active Tasks, but it will eventually converge to the correct count over time. @@ -716,7 +716,7 @@ The age is based on the creation time of the Task at the head of the queue. You can rely on both these counts when making scaling decisions. -#### Known accuracy limitations {#backlog-accuracy-limitations} +#### Known accuracy limitations {/* #backlog-accuracy-limitations */} These values are approximate. The most common sources: @@ -731,7 +731,7 @@ The most common sources: - **Sticky queue exclusion**: [Sticky queues](/sticky-execution) are not included in these values. Because Sticky queue Tasks only remain valid for a few seconds, this inaccuracy diminishes as the backlog grows. -### `TasksAddRate` and `TasksDispatchRate` {#TasksAddRate-and-TasksDispatchRate} +### `TasksAddRate` and `TasksDispatchRate` {/* #TasksAddRate-and-TasksDispatchRate */} Reports the approximate Tasks-per-second added to or dispatched from a Task Queue. This rate is averaged over the most recent 30-second time interval. @@ -743,7 +743,7 @@ The actual Task delivery count may be significantly higher than the number repor Tasks using Eager dispatch do not pass through Task Queues. - Tasks passed to Sticky Task Queues not included in the returned values for `TasksAddRate` and `TasksDispatchRate`. -### `BacklogIncreaseRate` {#BacklogIncreaseRate} +### `BacklogIncreaseRate` {/* #BacklogIncreaseRate */} Approximates the _net_ Tasks per second added to the backlog, averaged over the most recent 30 seconds. This is calculated as: @@ -757,7 +757,7 @@ TasksAddRate - TasksDispatchRate While individual `add` and `dispatch` rates may be inaccurate due to Eager and Sticky Task Queues, the `BacklogIncreaseRate` reliably reflects the rate at which the backlog is shrinking or growing for backlogs older than a few seconds. -## Evaluate Task Queue performance {#evaluate-worker-loads} +## Evaluate Task Queue performance {/* #evaluate-worker-loads */} A [Task Queue](https://docs.temporal.io/task-queue) is a lightweight, dynamically allocated queue. [Worker Entities](/workers#worker-entity) poll the queue for [Tasks](https://docs.temporal.io/tasks#task) and retrieve Tasks to work on. @@ -779,7 +779,7 @@ Evaluate your Worker loads and assess whether you need to scale up or reduce you ::: -### Query Task Queue info with Temporal CLI {#cli-task-queue-info} +### Query Task Queue info with Temporal CLI {/* #cli-task-queue-info */} The Temporal CLI helps you monitor and evaluate Worker performance. Issue the following command to display a list of active Workers that have recently polled a Task Queue: @@ -800,7 +800,7 @@ This feature may significantly change or be removed in a future release. ::: -### Query Task Queue info with the Go SDK {#go-sdk-task-queue-info} +### Query Task Queue info with the Go SDK {/* #go-sdk-task-queue-info */} Retrieve Task Queue data using the Go SDK by calling `DescribeTaskQueueEnhanced`. Specify the Task Queue name and set `ReportStats` to `true`, as in the following example: @@ -820,7 +820,7 @@ for _, taskQueueName := range taskQueueNames { } ``` -### Evaluate Worker availability and capacity issues {#worker-capacity-issues} +### Evaluate Worker availability and capacity issues {/* #worker-capacity-issues */} Each Temporal [Server](https://docs.temporal.io/temporal-service/temporal-server) records the last time of each poll request. This time is displayed in the `temporal task-queue describe` output. @@ -833,7 +833,7 @@ This time is displayed in the `temporal task-queue describe` output. - Values over 5 minutes since the last poll request usually suggest that Workers have shut down or been removed. Workers are removed if 5 minutes have passed since the last poll request. -### Manage your Worker fleet {#manage-your-worker-fleet} +### Manage your Worker fleet {/* #manage-your-worker-fleet */} You can adjust the number of Workers to enhance Workflow Execution performance and manage your fleet size. For instance, a large backlog of Tasks with too few Workers will slow down Workflow Execution completions and decrease processing efficiency. @@ -852,7 +852,7 @@ The values provided by `temporal task-queue describe` can help you manage your W As this rate increases, you may need to add more Workers until demand and capacity are balanced. As it decreases, you may be able to reduce your Worker fleet. -## Task Queue processing tuning {#task-queues-processing-tuning} +## Task Queue processing tuning {/* #task-queues-processing-tuning */} The following steps limit delays in Task Queue processing due to insufficient or unbalanced Workers. Review these steps if you notice high `schedule_to_start` metrics. diff --git a/docs/encyclopedia/activities/activity-definition.mdx b/docs/encyclopedia/activities/activity-definition.mdx index 051baa633e..4c0adcdabb 100644 --- a/docs/encyclopedia/activities/activity-definition.mdx +++ b/docs/encyclopedia/activities/activity-definition.mdx @@ -28,7 +28,7 @@ This page discusses the following: In day-to-day conversation, the term _Activity_ denotes an [Activity Definition](/activity-definition), [Activity Type](/activity-definition#activity-type), or [Activity Execution](/activity-execution). Temporal documentation aims to be explicit and differentiate between them. -## What is an Activity Definition? {#activity-definition} +## What is an Activity Definition? {/* #activity-definition */} An Activity Definition is the code that defines the constraints of an [Activity Task Execution](/tasks#activity-task-execution). Activities encapsulate business logic that is prone to failure, allowing for automatic retries when issues occur. @@ -184,7 +184,7 @@ Activity Definitions are named and referenced in code by their [Activity Type](/ title="Activity Definition" /> -### Idempotency {#idempotency} +### Idempotency {/* #idempotency */} Temporal recommends that Activities be idempotent. @@ -253,7 +253,7 @@ For an Activity with a [Retry Policy](/encyclopedia/retry-policies) that allows Be cautious when doing retries within your Activity because it lengthens the needed Activity timeout. Such internal retries also prevent users from counting failure metrics and make it harder for users to debug in Temporal UI when something is wrong. ::: -### Constraints {#activity-constraints} +### Constraints {/* #activity-constraints */} Activity Definitions are executed as normal functions. @@ -261,7 +261,7 @@ In the event of failure, the function begins at its initial state when retried ( Therefore, an Activity Definition has no restrictions on the code it contains. -### Parameters {#activity-parameters} +### Parameters {/* #activity-parameters */} An Activity Definition can support as many parameters as needed. @@ -276,7 +276,7 @@ Activity Definitions must contain the following parameters: Other parameters, such as [Retry Policies](/encyclopedia/retry-policies) and return values, can be seen in the implementation guides, listed in the next section. -## What is an Activity Type? {#activity-type} +## What is an Activity Type? {/* #activity-type */} An Activity Type is the mapping of a name to an Activity Definition. diff --git a/docs/encyclopedia/activities/activity-execution.mdx b/docs/encyclopedia/activities/activity-execution.mdx index 8ef7704e23..8367d6fa2a 100644 --- a/docs/encyclopedia/activities/activity-execution.mdx +++ b/docs/encyclopedia/activities/activity-execution.mdx @@ -25,7 +25,7 @@ This page discusses the following: - [Asynchronous Activity Completion](#asynchronous-activity-completion) - [Task Token](#task-token) -## What is an Activity Execution? {#activity-execution} +## What is an Activity Execution? {/* #activity-execution */} An Activity Execution is the full chain of [Activity Task Executions](/tasks#activity-task-execution). @@ -65,7 +65,7 @@ not be tried. ::: -## Cancellation {#cancellation} +## Cancellation {/* #cancellation */} Activity Cancellation: @@ -105,7 +105,7 @@ waiting. Cancellation can only be requested a single time. If you try to cancel your Activity Execution more than once, it will not receive more than one Cancellation request. -## What is an Activity Id? {#activity-id} +## What is an Activity Id? {/* #activity-id */} The identifier for an [Activity Execution](#activity-execution). The identifier can be generated by the system, or it can be provided by the Workflow code that spawns the Activity Execution. The identifier is unique among the open @@ -117,7 +117,7 @@ An Activity Id can be used to [complete the Activity asynchronously](#asynchrono [Standalone Activities](/standalone-activity) have a separate ID space from Workflows and other Temporal primitives. This means use of conflict policy (`USE_EXISTING`, …) and reuse policy (`REJECT_DUPLICATES`, …) will only observe the Standalone Activity ID space. -## What is Asynchronous Activity Completion? {#asynchronous-activity-completion} +## What is Asynchronous Activity Completion? {/* #asynchronous-activity-completion */} Asynchronous Activity Completion is a feature that enables an Activity Function to return without causing the Activity Execution to complete. The Temporal Client can then be used from anywhere to both Heartbeat Activity Execution progress @@ -185,7 +185,7 @@ will be retried in a minute. In the second scenario, the failure is retried sooner. This is particularly helpful in scenarios like this in which the external process might take a long time. -### What is a Task Token? {#task-token} +### What is a Task Token? {/* #task-token */} A Task Token is a unique identifier for an [Activity Task Execution](/tasks#activity-task-execution). diff --git a/docs/encyclopedia/activities/activity-operations.mdx b/docs/encyclopedia/activities/activity-operations.mdx index be4768469d..40640dc2ad 100644 --- a/docs/encyclopedia/activities/activity-operations.mdx +++ b/docs/encyclopedia/activities/activity-operations.mdx @@ -48,7 +48,7 @@ Activity Operations aren't available as SDK client methods. They're operational | [Reset](#reset) | Clears retry state (attempts, backoff) and schedules a new execution. | [`temporal activity reset`](/cli/activity#reset) | | [Update Options](#update-options) | Changes timeouts, Retry Policy, or Task Queue without restarting the Activity. | [`temporal activity update-options`](/cli/activity#update-options) | -## Pause {#pause} +## Pause {/* #pause */} Pause stops the Temporal Service from scheduling new retries of an [Activity Execution](/activity-execution). @@ -109,7 +109,7 @@ Your Activity code may need to handle these cases differently, for example relea - **Pause operates on individual Activities by ID within a single Workflow.** Unlike Unpause, Reset, and Update Options, there's no `--query` flag. To pause multiple Activities, issue separate commands for each Activity ID. - **No Namespace-wide query for Paused Activities.** You must know the Workflow Id. See [Observability](#observability). -## Unpause {#unpause} +## Unpause {/* #unpause */} Unpause resumes a Paused Activity Execution. @@ -145,7 +145,7 @@ See the [CLI reference for `temporal activity unpause`](/cli/activity#unpause) f - **A Paused Activity can time out before you Unpause it.** The [Schedule-To-Close Timeout](/encyclopedia/detecting-activity-failures#schedule-to-close-timeout) isn't stopped or extended while Paused. Use [`update-options`](#update-options) to extend the timeout before Unpausing if needed. - **Unpause doesn't interrupt or duplicate an in-flight execution.** If an Activity without Heartbeat is still running when you Unpause, it continues to completion. The Temporal Service doesn't schedule a concurrent execution. If the in-flight execution fails, the next retry proceeds normally. -## Reset {#reset} +## Reset {/* #reset */} Reset clears an Activity's retry state and schedules a fresh execution. @@ -206,7 +206,7 @@ Your Activity code may need to handle these cases differently, for example savin - **`--restore-original-options` restores the Activity's original configuration.** It reverts timeouts, Retry Policy, and Task Queue to the values from when the Activity was first scheduled. - **Bulk Reset can overwhelm downstream services.** When using `--query` to Reset Activities across many Workflows, use `--jitter` to stagger the restart times. -## Update Options {#update-options} +## Update Options {/* #update-options */} Update Options changes an Activity's runtime configuration without restarting it. @@ -250,7 +250,7 @@ See the [CLI reference for `temporal activity update-options`](/cli/activity#upd - **Update Options is CLI and gRPC only.** It's not available in the UI. -## Observability {#observability} +## Observability {/* #observability */} Activity Operations have a limited audit trail because they are not recorded in a Workflow's Event History. However, you can use the CLI and the UI to check Activity state and find Paused Activities for running Workflows. @@ -266,7 +266,7 @@ The `TemporalPauseInfo` [Search Attribute](/search-attribute) is filterable with There's no Namespace-wide query to find all Paused Activities across Workflows. You must know the Workflow Id. -### Audit trail {#audit-trail} +### Audit trail {/* #audit-trail */} Activity Operations don't produce Event History events. There is no record of a Pause, Reset, or option change in the Workflow's [Event History](/workflow-execution/event#event-history). diff --git a/docs/encyclopedia/activities/local-activity.mdx b/docs/encyclopedia/activities/local-activity.mdx index 864a12bc73..6534727c75 100644 --- a/docs/encyclopedia/activities/local-activity.mdx +++ b/docs/encyclopedia/activities/local-activity.mdx @@ -17,7 +17,7 @@ tags: This page discusses [Local Activity](#local-activity). -## What is a Local Activity? {#local-activity} +## What is a Local Activity? {/* #local-activity */} A Local Activity is an [Activity Execution](/activity-execution) that executes in the same process as the [Workflow Execution](/workflow-execution) that spawns it. diff --git a/docs/encyclopedia/activities/standalone-activity.mdx b/docs/encyclopedia/activities/standalone-activity.mdx index c635e9c150..c866ab0707 100644 --- a/docs/encyclopedia/activities/standalone-activity.mdx +++ b/docs/encyclopedia/activities/standalone-activity.mdx @@ -26,7 +26,7 @@ Standalone Activities are available as a [Public Preview](/evaluate/development- See [limitations](#public-preview-limitations) below. -## What is a Standalone Activity? {#standalone-activity} +## What is a Standalone Activity? {/* #standalone-activity */} If you need to orchestrate multiple Activities, use a [Workflow](/workflows). But if you just need to execute a single Activity, use a Standalone Activity. @@ -90,7 +90,7 @@ webhook, syncing data, or executing a single function reliably with built-in ret - Activity metrics - including counts for success, failure, timeout, and cancel - Dual use - execute Activities within a Workflow or standalone with no Worker code changes -## Observability {#observability} +## Observability {/* #observability */} All existing [Activity metrics](/cloud/metrics/openmetrics/metrics-reference#activity-metrics) apply to Standalone Activities. This includes counts for scheduled, started, completed, failed, timed out, diff --git a/docs/encyclopedia/child-workflows/parent-close-policy.mdx b/docs/encyclopedia/child-workflows/parent-close-policy.mdx index 54ab0e1b86..0d0a8420f4 100644 --- a/docs/encyclopedia/child-workflows/parent-close-policy.mdx +++ b/docs/encyclopedia/child-workflows/parent-close-policy.mdx @@ -31,7 +31,7 @@ import { CaptionedImage } from '@site/src/components'; This page discusses [Parent Close Policy](#parent-close-policy). -## What is a Parent Close Policy? {#parent-close-policy} +## What is a Parent Close Policy? {/* #parent-close-policy */} A Parent Close Policy determines what happens to a Child Workflow Execution if its Parent changes to a Closed status (Completed, Failed, or Timed out). diff --git a/docs/encyclopedia/data-conversion/codec-server.mdx b/docs/encyclopedia/data-conversion/codec-server.mdx index 920c06eec8..13e6205f3b 100644 --- a/docs/encyclopedia/data-conversion/codec-server.mdx +++ b/docs/encyclopedia/data-conversion/codec-server.mdx @@ -79,7 +79,7 @@ form. Your Codec Server should use the same Payload Codec implementation as your Workers to ensure consistent encoding and decoding. -## Codec Server with External Storage {#external-storage} +## Codec Server with External Storage {/* #external-storage */} When your Workers and Clients use [External Storage](/external-storage), your storage drivers replace some payloads in the Event History with small references that point to data in an external store like Amazon S3. The Temporal Service and diff --git a/docs/encyclopedia/data-conversion/dataconversion.mdx b/docs/encyclopedia/data-conversion/dataconversion.mdx index 6171458474..22170b4e30 100644 --- a/docs/encyclopedia/data-conversion/dataconversion.mdx +++ b/docs/encyclopedia/data-conversion/dataconversion.mdx @@ -50,7 +50,7 @@ For details, see the API references: - [Python](https://python.temporal.io/temporalio.converter.DataConverter.html) - [TypeScript](https://typescript.temporal.io/api/interfaces/common.DataConverter) -### What is a Payload? {#payload} +### What is a Payload? {/* #payload */} A [Payload](https://api-docs.temporal.io/#temporal.api.common.v1.Payload) represents binary data such as input and output from Activities and Workflows. Payloads also contain metadata that describe their data type or other parameters for use by custom encoders/converters. diff --git a/docs/encyclopedia/data-conversion/default-custom-data-converter.mdx b/docs/encyclopedia/data-conversion/default-custom-data-converter.mdx index 275d83adbb..29ae6f4a25 100644 --- a/docs/encyclopedia/data-conversion/default-custom-data-converter.mdx +++ b/docs/encyclopedia/data-conversion/default-custom-data-converter.mdx @@ -26,7 +26,7 @@ This page discusses the following: - [Default Data Converter](#default-data-converter) - [Custom Data Converter](#custom-data-converter) -## What is a default Data Converter? {#default-data-converter} +## What is a default Data Converter? {/* #default-data-converter */} Each Temporal SDK includes and uses a default Data Converter. The default Data Converter converts objects to bytes using a series of Payload Converters and supports binary, Protobufs, and JSON formats. @@ -47,7 +47,7 @@ For example: The default Data Converter serializes objects based on their root type, rather than nested types. The JSON serializers of some SDKs cannot process lists with Protobuf children objects without implementing a [custom Data Converter](#custom-data-converter). -## What is a custom Data Converter? {#custom-data-converter} +## What is a custom Data Converter? {/* #custom-data-converter */} A custom Data Converter extends the default Data Converter with custom logic for [Payload](/dataconversion#payload) conversion or encoding. diff --git a/docs/encyclopedia/data-conversion/external-storage.mdx b/docs/encyclopedia/data-conversion/external-storage.mdx index 6beccf9109..19441bb54b 100644 --- a/docs/encyclopedia/data-conversion/external-storage.mdx +++ b/docs/encyclopedia/data-conversion/external-storage.mdx @@ -69,7 +69,7 @@ For SDK-specific usage guides, see: - [Go SDK: Large payload storage](/develop/go/data-handling/external-storage) - [Python SDK: Large payload storage](/develop/python/data-handling/external-storage) -## How External Storage fits in the data conversion pipeline {#data-pipeline} +## How External Storage fits in the data conversion pipeline {/* #data-pipeline */} During [Data Conversion](/dataconversion), External Storage sits at the end of the pipeline, after both the [Payload Converter](/payload-converter) and the [Payload Codec](/payload-codec): @@ -132,7 +132,7 @@ Configure External Storage on the Data Converter. The key settings are: - **Driver selector**. When using multiple drivers, you must provide a function that chooses which driver handles each payload. -## Lifecycle management for external storage {#lifecycle} +## Lifecycle management for external storage {/* #lifecycle */} Temporal does not automatically delete payloads from your external store. Payloads can also be orphaned if a request fails after the upload completes. We recommend you configure a lifecycle policy that both ensures these payloads are @@ -153,7 +153,7 @@ based on your operational needs. Use [Continue-as-New](/workflow-execution/conti run longer. The new run uploads fresh payloads, and the old run's payloads only need to survive through its retention period. -## Durable External Storage {#durable-external-storage} +## Durable External Storage {/* #durable-external-storage */} External Storage stores payloads in a single storage backend. If that backend becomes unavailable, Workers can't retrieve payloads. To protect against regional or provider failures, implement your drivers in a way that takes diff --git a/docs/encyclopedia/data-conversion/failure-converter.mdx b/docs/encyclopedia/data-conversion/failure-converter.mdx index b904f69f7e..9d12ffb8fe 100644 --- a/docs/encyclopedia/data-conversion/failure-converter.mdx +++ b/docs/encyclopedia/data-conversion/failure-converter.mdx @@ -22,7 +22,7 @@ tags: This page discusses [Failure Converter](#failure-converter). -## What is a Failure Converter? {#failure-converter} +## What is a Failure Converter? {/* #failure-converter */} As with input and output, Temporal also uses its own default converter logic for errors that are generated by Workflows. The default Failure Converter copies error messages and call stacks as plain text, and this text output is then directly accessible in the `Message` field of these Workflow Executions. diff --git a/docs/encyclopedia/data-conversion/key-management.mdx b/docs/encyclopedia/data-conversion/key-management.mdx index 81b2c1959c..e1c0505495 100644 --- a/docs/encyclopedia/data-conversion/key-management.mdx +++ b/docs/encyclopedia/data-conversion/key-management.mdx @@ -22,7 +22,7 @@ tags: This page discusses [Key Management](#key-management). -## What is Key Management? {#key-management} +## What is Key Management? {/* #key-management */} Key Management is a fundamental part of working with encryption keys. diff --git a/docs/encyclopedia/data-conversion/payload-codec.mdx b/docs/encyclopedia/data-conversion/payload-codec.mdx index 04f723dcdc..9d9636c24f 100644 --- a/docs/encyclopedia/data-conversion/payload-codec.mdx +++ b/docs/encyclopedia/data-conversion/payload-codec.mdx @@ -22,7 +22,7 @@ tags: This page discusses [Payload Codec](#payload-codec). -## What is a Payload Codec? {#payload-codec} +## What is a Payload Codec? {/* #payload-codec */} A Payload Codec transforms an array of [Payloads](/dataconversion#payload) (for example, a list of Workflow arguments) into another array of Payloads. @@ -31,7 +31,7 @@ When deserializing from Payloads, codecs are applied first to last to reverse th Use a custom Payload Codec to transform your Payloads; for example, implementing compression and/or encryption on your Workflow Execution data. -### Encryption {#encryption} +### Encryption {/* #encryption */} Using end-to-end encryption in your custom Data Converter ensures that sensitive application data is secure when handled by the Temporal Server. diff --git a/docs/encyclopedia/data-conversion/payload-converter.mdx b/docs/encyclopedia/data-conversion/payload-converter.mdx index 310d1fbbfa..099a3de4b9 100644 --- a/docs/encyclopedia/data-conversion/payload-converter.mdx +++ b/docs/encyclopedia/data-conversion/payload-converter.mdx @@ -22,14 +22,14 @@ tags: This page discusses [Payload Converter](#payload-converter). -## What is a Payload Converter? {#payload-converter} +## What is a Payload Converter? {/* #payload-converter */} A Payload Converter serializes data, converting values to bytes and back. When you initiate a Workflow Execution through a Client and pass data as input, the input is serialized using a Data Converter that runs it through a set of Payload Converters. When your Workflow Execution starts, this data input is deserialized and passed as input to your Workflow. -### Composite Data Converters {#composite-data-converters} +### Composite Data Converters {/* #composite-data-converters */} A Composite Data Converter is used to apply custom, type-specific Payload Converters in a specified order. A Composite Data Converter can be comprised of custom rules that you created, and it can also leverage the default Data Converters built into Temporal. diff --git a/docs/encyclopedia/data-conversion/remote-data-encoding.mdx b/docs/encyclopedia/data-conversion/remote-data-encoding.mdx index 5c2fee8c84..13d87b7630 100644 --- a/docs/encyclopedia/data-conversion/remote-data-encoding.mdx +++ b/docs/encyclopedia/data-conversion/remote-data-encoding.mdx @@ -22,7 +22,7 @@ tags: This page discusses [Remote Data Encoding](#remote-data-encoding). -## What is remote data encoding? {#remote-data-encoding} +## What is remote data encoding? {/* #remote-data-encoding */} Remote data encoding is exposing your Payload Codec via HTTP endpoints to support remote encoding and decoding. diff --git a/docs/encyclopedia/detecting-activity-failures.mdx b/docs/encyclopedia/detecting-activity-failures.mdx index 5a509d0a08..f41a03793c 100644 --- a/docs/encyclopedia/detecting-activity-failures.mdx +++ b/docs/encyclopedia/detecting-activity-failures.mdx @@ -24,7 +24,7 @@ A Workflow can detect different kinds of Activity Execution failures through the - [Schedule-To-Close Timeout](#schedule-to-close-timeout) - [Activity Heartbeats](#activity-heartbeat) -## Schedule-To-Start Timeout {#schedule-to-start-timeout} +## Schedule-To-Start Timeout {/* #schedule-to-start-timeout */} **What is a Schedule-To-Start Timeout in Temporal?** @@ -73,7 +73,7 @@ We do not recommend using this timeout unless you know what you are doing. In most cases, we recommend monitoring the `temporal_activity_schedule_to_start_latency` metric to know when Workers slow down picking up Activity Tasks, instead of setting this timeout. -## Start-To-Close Timeout {#start-to-close-timeout} +## Start-To-Close Timeout {/* #start-to-close-timeout */} **What is a Start-To-Close Timeout in Temporal?** @@ -126,7 +126,7 @@ If this timeout is reached, the following actions occur: - The attempt count increments by 1 in the Workflow Execution's mutable state. - The Start-To-Close Timeout timer is reset. -## Schedule-To-Close Timeout {#schedule-to-close-timeout} +## Schedule-To-Close Timeout {/* #schedule-to-close-timeout */} **What is a Schedule-To-Close Timeout in Temporal?** @@ -166,7 +166,7 @@ Therefore, the Temporal Server relies on the Start-To-Close Timeout to force Act ::: -## Activity Heartbeat {#activity-heartbeat} +## Activity Heartbeat {/* #activity-heartbeat */} **What is an Activity Heartbeat in Temporal?** @@ -250,7 +250,7 @@ And the following scenarios are not suitable for Heartbeating: - Making a quick API call. - Reading a small file from disk. -### Heartbeat Timeout {#heartbeat-timeout} +### Heartbeat Timeout {/* #heartbeat-timeout */} **What is a Heartbeat Timeout in Temporal?** diff --git a/docs/encyclopedia/detecting-workflow-failures.mdx b/docs/encyclopedia/detecting-workflow-failures.mdx index bf19cfcd73..31aff18679 100644 --- a/docs/encyclopedia/detecting-workflow-failures.mdx +++ b/docs/encyclopedia/detecting-workflow-failures.mdx @@ -27,7 +27,7 @@ If you need to perform an action inside your Workflow after a specific period of - [Workflow Run Timeout](#workflow-run-timeout) - [Workflow Task Timeout](#workflow-task-timeout) -## Workflow Execution Timeout {#workflow-execution-timeout} +## Workflow Execution Timeout {/* #workflow-execution-timeout */} **What is a Workflow Execution Timeout in Temporal?** @@ -52,7 +52,7 @@ If this timeout is reached, the Workflow Execution changes to a Timed Out status This timeout is different from the [Workflow Run Timeout](#workflow-run-timeout). This timeout is most commonly used for stopping the execution of a [Temporal Cron Job](/cron-job) after a certain amount of time has passed. -## Workflow Run Timeout {#workflow-run-timeout} +## Workflow Run Timeout {/* #workflow-run-timeout */} **What is a Workflow Run Timeout in Temporal?** @@ -81,7 +81,7 @@ This timeout is most commonly used to limit the execution time of a single [Temp If the Workflow Run Timeout is reached, the Workflow Execution will be Timed Out. -## Workflow Task Timeout {#workflow-task-timeout} +## Workflow Task Timeout {/* #workflow-task-timeout */} **What is a Workflow Task Timeout in Temporal?** diff --git a/docs/encyclopedia/event-history/dotnet.mdx b/docs/encyclopedia/event-history/dotnet.mdx index 7340ce9519..6e3c86261f 100644 --- a/docs/encyclopedia/event-history/dotnet.mdx +++ b/docs/encyclopedia/event-history/dotnet.mdx @@ -40,7 +40,7 @@ In order to understand how Workflow Replay works, this page will go through the 3. [How History Replay Provides Durable Execution](#How-History-Replay-Provides-Durable-Execution) 4. [Example of a Non-Deterministic Workflow](#Example-of-Non-Deterministic-Workflow) -## How Workflow Code Maps to Commands {#How-Workflow-Code-Maps-To-Commands} +## How Workflow Code Maps to Commands {/* #How-Workflow-Code-Maps-To-Commands */} This walkthrough will cover how the Workflow code maps to Commands that get sent to the Temporal Service, letting the Temporal Service know what to do. @@ -75,7 +75,7 @@ images={[ ]} /> -## How Workflow Commands Map to Events {#How-Workflow-Commands-Map-To-Events} +## How Workflow Commands Map to Events {/* #How-Workflow-Commands-Map-To-Events */} The Commands that are sent to the Temporal Service are then turned into Events, which build up the Event History. The Event History is a detailed log of Events that occur during the lifecycle of a Workflow Execution, such as the execution @@ -119,7 +119,7 @@ These Events are what are used to recreate a Workflow Execution's state in the c ]} /> -## How History Replay Provides Durable Execution {#How-History-Replay-Provides-Durable-Execution} +## How History Replay Provides Durable Execution {/* #How-History-Replay-Provides-Durable-Execution */} Now that you have seen how code maps to Commands, and how Commands map to Events, this next walkthrough will take a look at how Temporal uses Replay with the Events to provide Durable Execution and restore a Workflow Execution in the case of @@ -250,7 +250,7 @@ the Workflow Execution, ultimately resulting in a completed execution that's ide ]} /> -## Example of a Non-Deterministic Workflow {#Example-of-Non-Deterministic-Workflow} +## Example of a Non-Deterministic Workflow {/* #Example-of-Non-Deterministic-Workflow */} Now that Replay has been covered, this section will explain why Workflows need to be [deterministic](https://docs.temporal.io/workflow-definition#deterministic-constraints) in order for Replay to work. diff --git a/docs/encyclopedia/event-history/go.mdx b/docs/encyclopedia/event-history/go.mdx index 2df409ca37..737bcc6558 100644 --- a/docs/encyclopedia/event-history/go.mdx +++ b/docs/encyclopedia/event-history/go.mdx @@ -39,7 +39,7 @@ In order to understand how Workflow Replay works, this page will go through the 3. [How History Replay Provides Durable Execution](#How-History-Replay-Provides-Durable-Execution) 4. [Example of a Non-Deterministic Workflow](#Example-of-Non-Deterministic-Workflow) -## How Workflow Code Maps to Commands {#How-Workflow-Code-Maps-To-Commands} +## How Workflow Code Maps to Commands {/* #How-Workflow-Code-Maps-To-Commands */} This walkthrough will cover how the Workflow code maps to Commands that get sent to the Temporal Service, letting the Temporal Service know what to do. @@ -73,7 +73,7 @@ Temporal Service know what to do. ]} /> -## How Workflow Commands Map to Events {#How-Workflow-Commands-Map-To-Events} +## How Workflow Commands Map to Events {/* #How-Workflow-Commands-Map-To-Events */} The Commands that are sent to the Temporal Service are then turned into Events, which build up the Event History. The Event History is a detailed log of Events that occur during the lifecycle of a Workflow Execution, such as the execution @@ -117,7 +117,7 @@ These Events are what are used to recreate a Workflow Execution's state in the c ]} /> -## How History Replay Provides Durable Execution {#How-History-Replay-Provides-Durable-Execution} +## How History Replay Provides Durable Execution {/* #How-History-Replay-Provides-Durable-Execution */} Now that you have seen how code maps to Commands, and how Commands map to Events, this next walkthrough will take a look at how Temporal uses Replay with the Events to provide Durable Execution and restore a Workflow Execution in the case of @@ -264,7 +264,7 @@ the Workflow Execution, ultimately resulting in a completed execution that's ide ]} /> -## Example of a Non-Deterministic Workflow {#Example-of-Non-Deterministic-Workflow} +## Example of a Non-Deterministic Workflow {/* #Example-of-Non-Deterministic-Workflow */} Now that Replay has been covered, this section will explain why Workflows need to be [deterministic](https://docs.temporal.io/workflow-definition#deterministic-constraints) in order for Replay to work. diff --git a/docs/encyclopedia/event-history/java.mdx b/docs/encyclopedia/event-history/java.mdx index 2f71c23979..b2f03e68cc 100644 --- a/docs/encyclopedia/event-history/java.mdx +++ b/docs/encyclopedia/event-history/java.mdx @@ -39,7 +39,7 @@ In order to understand how Workflow Replay works, this page will go through the 3. [How History Replay Provides Durable Execution](#How-History-Replay-Provides-Durable-Execution) 4. [Example of a Non-Deterministic Workflow](#Example-of-Non-Deterministic-Workflow) -## How Workflow Code Maps to Commands {#How-Workflow-Code-Maps-To-Commands} +## How Workflow Code Maps to Commands {/* #How-Workflow-Code-Maps-To-Commands */} This walkthrough will cover how the Workflow code maps to Commands that get sent to the Temporal Service, letting the Temporal Service know what to do. @@ -73,7 +73,7 @@ Temporal Service know what to do. ]} /> -## How Workflow Commands Map to Events {#How-Workflow-Commands-Map-To-Events} +## How Workflow Commands Map to Events {/* #How-Workflow-Commands-Map-To-Events */} The Commands that are sent to the Temporal Service are then turned into Events, which build up the Event History. The Event History is a detailed log of Events that occur during the lifecycle of a Workflow Execution, such as the execution @@ -117,7 +117,7 @@ These Events are what are used to recreate a Workflow Execution's state in the c ]} /> -## How History Replay Provides Durable Execution {#How-History-Replay-Provides-Durable-Execution} +## How History Replay Provides Durable Execution {/* #How-History-Replay-Provides-Durable-Execution */} Now that you have seen how code maps to Commands, and how Commands map to Events, this next walkthrough will take a look at how Temporal uses Replay with the Events to provide Durable Execution and restore a Workflow Execution in the case of @@ -254,7 +254,7 @@ the Workflow Execution, ultimately resulting in a completed execution that's ide ]} /> -## Example of a Non-Deterministic Workflow {#Example-of-Non-Deterministic-Workflow} +## Example of a Non-Deterministic Workflow {/* #Example-of-Non-Deterministic-Workflow */} Now that Replay has been covered, this section will explain why Workflows need to be [deterministic](https://docs.temporal.io/workflow-definition#deterministic-constraints) in order for Replay to work. diff --git a/docs/encyclopedia/event-history/python.mdx b/docs/encyclopedia/event-history/python.mdx index dcf7691d69..7cd0e0670f 100644 --- a/docs/encyclopedia/event-history/python.mdx +++ b/docs/encyclopedia/event-history/python.mdx @@ -39,7 +39,7 @@ In order to understand how Workflow Replay works, this page will go through the 3. [How History Replay Provides Durable Execution](#How-History-Replay-Provides-Durable-Execution) 4. [Example of a Non-Deterministic Workflow](#Example-of-Non-Deterministic-Workflow) -## How Workflow Code Maps to Commands {#How-Workflow-Code-Maps-To-Commands} +## How Workflow Code Maps to Commands {/* #How-Workflow-Code-Maps-To-Commands */} This walkthrough will cover how the Workflow code maps to Commands that get sent to the Temporal Service, letting the Temporal Service know what to do. @@ -73,7 +73,7 @@ Temporal Service know what to do. ]} /> -## How Workflow Commands Map to Events {#How-Workflow-Commands-Map-To-Events} +## How Workflow Commands Map to Events {/* #How-Workflow-Commands-Map-To-Events */} The Commands that are sent to the Temporal Service are then turned into Events, which build up the Event History. The Event History is a detailed log of Events that occur during the lifecycle of a Workflow Execution, such as the execution @@ -117,7 +117,7 @@ These Events are what are used to recreate a Workflow Execution's state in the c ]} /> -## How History Replay Provides Durable Execution {#How-History-Replay-Provides-Durable-Execution} +## How History Replay Provides Durable Execution {/* #How-History-Replay-Provides-Durable-Execution */} Now that you have seen how code maps to Commands, and how Commands map to Events, this next walkthrough will take a look at how Temporal uses Replay with the Events to provide Durable Execution and restore a Workflow Execution in the case of @@ -256,7 +256,7 @@ the Workflow Execution, ultimately resulting in a completed execution that's ide ]} /> -## Example of a Non-Deterministic Workflow {#Example-of-Non-Deterministic-Workflow} +## Example of a Non-Deterministic Workflow {/* #Example-of-Non-Deterministic-Workflow */} Now that Replay has been covered, this section will explain why Workflows need to be [deterministic](https://docs.temporal.io/workflow-definition#deterministic-constraints) in order for Replay to work. diff --git a/docs/encyclopedia/event-history/typescript.mdx b/docs/encyclopedia/event-history/typescript.mdx index a86f85ceff..6c5fd773ff 100644 --- a/docs/encyclopedia/event-history/typescript.mdx +++ b/docs/encyclopedia/event-history/typescript.mdx @@ -39,7 +39,7 @@ In order to understand how Workflow Replay works, this page will go through the 3. [How History Replay Provides Durable Execution](#How-History-Replay-Provides-Durable-Execution) 4. [Example of a Non-Deterministic Workflow](#Example-of-Non-Deterministic-Workflow) -## How Workflow Code Maps to Commands {#How-Workflow-Code-Maps-To-Commands} +## How Workflow Code Maps to Commands {/* #How-Workflow-Code-Maps-To-Commands */} This walkthrough will cover how the Workflow code maps to Commands that get sent to the Temporal Service, letting the Temporal Service know what to do. @@ -75,7 +75,7 @@ Temporal Service know what to do. ]} /> -## How Workflow Commands Map to Events {#How-Workflow-Commands-Map-To-Events} +## How Workflow Commands Map to Events {/* #How-Workflow-Commands-Map-To-Events */} The Commands that are sent to the Temporal Service are then turned into Events, which build up the Event History. The Event History is a detailed log of Events that occur during the lifecycle of a Workflow Execution, such as the execution @@ -119,7 +119,7 @@ These Events are what are used to recreate a Workflow Execution's state in the c ]} /> -## How History Replay Provides Durable Execution {#How-History-Replay-Provides-Durable-Execution} +## How History Replay Provides Durable Execution {/* #How-History-Replay-Provides-Durable-Execution */} Now that you have seen how code maps to Commands, and how Commands map to Events, this next walkthrough will take a look at how Temporal uses Replay with the Events to provide Durable Execution and restore a Workflow Execution in the case of @@ -258,7 +258,7 @@ the Workflow Execution, ultimately resulting in a completed execution that's ide ]} /> -## Example of a Non-Deterministic Workflow {#Example-of-Non-Deterministic-Workflow} +## Example of a Non-Deterministic Workflow {/* #Example-of-Non-Deterministic-Workflow */} Now that Replay has been covered, this section will explain why Workflows need to be [deterministic](https://docs.temporal.io/workflow-definition#deterministic-constraints) in order for Replay to work. diff --git a/docs/encyclopedia/namespaces/global-namespaces.mdx b/docs/encyclopedia/namespaces/global-namespaces.mdx index 2ba2d246fb..020c4a3213 100644 --- a/docs/encyclopedia/namespaces/global-namespaces.mdx +++ b/docs/encyclopedia/namespaces/global-namespaces.mdx @@ -14,7 +14,7 @@ tags: This page provides an overview of Global Namespace. -## What is a Global Namespace? {#global-namespace} +## What is a Global Namespace? {/* #global-namespace */} A Global Namespace is a [Namespace](/namespaces) that exists across Clusters when [Multi-Cluster Replication](/temporal-service/multi-cluster-replication) is set up. diff --git a/docs/encyclopedia/nexus/nexus-operations.mdx b/docs/encyclopedia/nexus/nexus-operations.mdx index 1503131368..a2e5be6be2 100644 --- a/docs/encyclopedia/nexus/nexus-operations.mdx +++ b/docs/encyclopedia/nexus/nexus-operations.mdx @@ -40,7 +40,7 @@ Temporal Nexus is now [Generally Available](/evaluate/development-production-fea [Nexus Operations](/glossary#nexus-operation) can be synchronous or asynchronous. Unlike a traditional RPC, an asynchronous Nexus Operation has an operation token that can be used to re-attach to a long-running Operation backed by a Workflow. An Operation's lifecycle spans scheduling, reliable delivery with retries, handler execution, and result or callback completion. -## SDK support {#sdk-support} +## SDK support {/* #sdk-support */} :::tip SDK GUIDES @@ -60,7 +60,7 @@ An Operation's lifecycle spans scheduling, reliable delivery with retries, handl - **New-Sync-Operation** - Run a synchronous Operation: invoke a Query, Signal, or Update, or execute other reliable code using the Temporal SDK Client. -## Nexus Operation lifecycle {#operation-lifecycle} +## Nexus Operation lifecycle {/* #operation-lifecycle */} When a caller Workflow executes a Nexus Operation, the command is atomically handed off to the [Nexus Machinery](/glossary#nexus-machinery). The Machinery ensures [at-least-once](#at-least-once-execution-semantics-and-idempotency) execution with [automatic retries](#automatic-retries) and reliable result delivery. @@ -105,7 +105,7 @@ Timed-out handlers are retried until the Operation's Schedule-to-Close timeout i ::: -### Asynchronous Operation lifecycle {#asynchronous-operation-lifecycle} +### Asynchronous Operation lifecycle {/* #asynchronous-operation-lifecycle */} Asynchronous Operations can run up to [60 days](/cloud/limits#nexus-operation-duration-limits) (the maximum Schedule-to-Close timeout in Temporal Cloud). Differences from the synchronous lifecycle are in **bold**. @@ -134,7 +134,7 @@ Differences from the synchronous lifecycle are in **bold**. title="Nexus" /> -### Executing code from a synchronous handler {#executing-arbitrary-code-from-a-sync-handler} +### Executing code from a synchronous handler {/* #executing-arbitrary-code-from-a-sync-handler */} Synchronous handlers can execute code directly but must complete within the [handler deadline](/cloud/limits#nexus-operation-request-timeout). Use the Temporal SDK Client to invoke Signals, Queries, Updates, or other reliable code. @@ -168,7 +168,7 @@ At a high level, when a caller Workflow executes a Nexus Operation: 3. The handler processes the task and returns the result (synchronous) or an Operation token (asynchronous). 4. The caller's Nexus Machinery records a NexusOperation event ([Started](/references/events#nexusoperationstarted), [Completed](/references/events#nexusoperationcompleted), [Failed](/references/events#nexusoperationfailed), [Canceled](/references/events#nexusoperationcanceled), or [TimedOut](/references/events#nexusoperationtimedout)) in the caller's Event History. -## Automatic retries {#automatic-retries} +## Automatic retries {/* #automatic-retries */} Once the caller Workflow schedules an Operation with the caller's Temporal Service, the caller's Nexus Machinery keeps trying to start the Operation. If a [retryable Nexus error](/references/failures#nexus-errors) is returned the Nexus Machinery will retry until the Nexus Operation's [Schedule-to-Start timeout](#schedule-to-start-timeout) or [Schedule-to-close timeout](#schedule-to-close-timeout) is exceeded. @@ -183,12 +183,12 @@ See [errors in Activities](/references/failures#errors-in-activities) and [non-r To control retry behavior, return a [non-retryable Nexus error](/references/failures#non-retryable-nexus-errors). See [errors in Nexus handlers](/nexus/error-handling#errors-in-nexus-handlers). -## Timeouts {#timeouts} +## Timeouts {/* #timeouts */} Nexus Operations support three types of timeouts that control how long the caller is willing to wait at different stages of the Operation lifecycle. These timeouts are set by the caller when scheduling the Operation. -### Schedule-to-Close timeout {#schedule-to-close-timeout} +### Schedule-to-Close timeout {/* #schedule-to-close-timeout */} The Schedule-to-Close timeout limits the total duration from when the Operation is scheduled to when it completes. This is the overall timeout for the entire Operation. @@ -198,7 +198,7 @@ This timeout covers the full [Nexus Operation lifecycle](https://docs.temporal.i In Temporal Cloud, the [maximum Schedule-to-Close timeout is 60 days](https://docs.temporal.io/cloud/limits#nexus-operation-duration-limits). -### Schedule-to-Start timeout {#schedule-to-start-timeout} +### Schedule-to-Start timeout {/* #schedule-to-start-timeout */} The Schedule-to-Start timeout limits how long the caller is willing to wait for the Operation to be started (or completed, if synchronous) by the handler. If the Operation is not started within this timeout, it fails with `TIMEOUT_TYPE_SCHEDULE_TO_START`. @@ -211,7 +211,7 @@ The Schedule-to-Start timeout requires Temporal Server version 1.31.0 or later. ::: -### Start-to-Close timeout {#start-to-close-timeout} +### Start-to-Close timeout {/* #start-to-close-timeout */} The Start-to-Close timeout limits how long the caller is willing to wait for an asynchronous Operation to complete after it has been started. If the Operation does not complete within this timeout after starting, it fails with `TIMEOUT_TYPE_START_TO_CLOSE`. @@ -227,7 +227,7 @@ The Start-to-Close timeout requires Temporal Server version 1.31.0 or later. ::: -## Circuit breaking {#circuit-breaking} +## Circuit breaking {/* #circuit-breaking */} Nexus implements circuit breaking per caller-Namespace/Endpoint pair ("destination pair"). Each destination pair trips and resets independently. @@ -309,7 +309,7 @@ Pending Nexus Operations: 1 CancelationBlockedReason The circuit breaker is open. ``` -## Execution semantics {#execution-semantics} +## Execution semantics {/* #execution-semantics */} ### At-least-once execution semantics and idempotency @@ -338,13 +338,13 @@ difficult to detect and correlate. If the Nexus Operation was part of a multi-st to run compensation logic, potentially leaving the system in a partially completed state. Prefer [cancellation](#cancelation) when possible. -## Versioning {#versioning} +## Versioning {/* #versioning */} Task Routing is the simplest way to version Nexus service code. For backward-incompatible changes, use a different Service name and Task Queue (for example, `prod.payments.v2`). Callers migrate to the new version on their own deployment schedule. -## Attaching multiple Nexus callers to a handler Workflow {#attaching-multiple-nexus-callers} +## Attaching multiple Nexus callers to a handler Workflow {/* #attaching-multiple-nexus-callers */} Operations started with [New-Workflow-Run-Operation](/nexus/operations#sdk-support) automatically attach a completion Callback to the handler Workflow. diff --git a/docs/encyclopedia/nexus/nexus-patterns.mdx b/docs/encyclopedia/nexus/nexus-patterns.mdx index 2b99c27307..b2a308f3b6 100644 --- a/docs/encyclopedia/nexus/nexus-patterns.mdx +++ b/docs/encyclopedia/nexus/nexus-patterns.mdx @@ -28,7 +28,7 @@ There are two common patterns for building and deploying [Nexus Services](/nexus - **[Router pattern](#router-queue-pattern)**: Separates Nexus routing from Workflow execution. A dedicated Nexus Worker on a “router” Task Queue routes Operations to Workflows on other Task Queues. Use when you need independent scaling, different IAM permissions per Worker fleet, or want to add Nexus to without modifying existing Workers. -## Collocated pattern (default) {#collocated-pattern} +## Collocated pattern (default) {/* #collocated-pattern */} The **collocated pattern** runs Nexus Operation handlers in the same Worker and on the same Task Queue as the underlying Workflows. This is the default and simplest deployment. diff --git a/docs/encyclopedia/nexus/nexus-security.mdx b/docs/encyclopedia/nexus/nexus-security.mdx index 8f266f541b..b84589de7e 100644 --- a/docs/encyclopedia/nexus/nexus-security.mdx +++ b/docs/encyclopedia/nexus/nexus-security.mdx @@ -28,7 +28,7 @@ Temporal Nexus is now [Generally Available](/evaluate/development-production-fea Temporal Cloud provides built-in Endpoint access controls and secure connectivity across Namespaces. Self-hosted deployments can implement [custom Authorizers](/self-hosted-guide/security#authorizer-plugin). -## Runtime access controls {#runtime-access-controls} +## Runtime access controls {/* #runtime-access-controls */} In Temporal Cloud, each Endpoint has an access control policy: an allowlist of caller Namespaces. @@ -43,7 +43,7 @@ Temporal Cloud acts as a trusted broker across Namespace boundaries. See [Configure runtime access controls](/nexus/registry#configure-runtime-access-controls). -## Secure connectivity {#secure-connectivity} +## Secure connectivity {/* #secure-connectivity */} :::info @@ -59,7 +59,7 @@ Temporal Cloud secures all Nexus communication: - mTLS encrypts all cross-Namespace Nexus traffic (start, cancel, and completion callbacks) across cells and regions. - Endpoints are only accessible from within a Temporal Cloud Account through the Temporal SDK - not externally accessible. -## Payload encryption and Data Converter {#payload-encryption-data-converter} +## Payload encryption and Data Converter {/* #payload-encryption-data-converter */} Nexus uses the same Data Converter as Workflows and Activities - JSON, Proto, and binary payloads are all supported. If you use a Codec for encryption, it also encrypts Nexus payloads. @@ -69,12 +69,12 @@ Payloads are encrypted by the sender (caller encrypts input, handler encrypts re Three common approaches for cross-Namespace payload encryption: -### Option 1: Same encryption key {#same-encryption-key} +### Option 1: Same encryption key {/* #same-encryption-key */} Both Namespaces share the same encryption key. Simplest approach - no additional configuration needed. -### Option 2: Pass KMS key ID in payload metadata {#kms-key-id-metadata} +### Option 2: Pass KMS key ID in payload metadata {/* #kms-key-id-metadata */} Each Namespace uses its own encryption key, with the KMS key ID passed in Temporal payload metadata. The receiver reads the key ID from metadata and decrypts using KMS IAM permissions. @@ -84,7 +84,7 @@ The Codec Server needs KMS decrypt permissions for all relevant keys. See the [encryption sample](https://github.com/temporalio/samples-go/blob/main/encryption/data_converter.go) and the [reference-app-orders-go data converter](https://github.com/temporalio/reference-app-orders-go/blob/main/app/temporalutil/data_converter.go). -### Option 3: Wrapper types for endpoint-specific encryption keys {#endpoint-specific-keys} +### Option 3: Wrapper types for endpoint-specific encryption keys {/* #endpoint-specific-keys */} Use wrapper types (for example, `EndpointValue`) so the Data Converter selects an Endpoint-specific encryption key. This encrypts only Nexus traffic with a dedicated key, without sharing Namespace keys across teams. @@ -96,7 +96,7 @@ See the [draft endpoint-based encryption sample](https://github.com/temporalio/s Options 1 and 2, where both sides share the same key or flow the KMS key ID in payload metadata, work with the standard Data Converter. Option 3 is more advanced and is intended for teams that don't want to share their Namespace encryption keys with other teams. -## Nexus Registry security {#managing-nexus-endpoints} +## Nexus Registry security {/* #managing-nexus-endpoints */} See [Nexus Registry Roles and Permissions](/nexus/registry#roles-and-permissions). diff --git a/docs/encyclopedia/retry-policies.mdx b/docs/encyclopedia/retry-policies.mdx index 4c8b013042..7a94b1d1f6 100644 --- a/docs/encyclopedia/retry-policies.mdx +++ b/docs/encyclopedia/retry-policies.mdx @@ -201,7 +201,7 @@ Non-Retryable Errors = [] using the Workflow Execution Timeout for [Workflows](/workflows) or the Schedule-To-Close Timeout for Activities to limit the total duration of retries, rather than using this attribute. -### Non-Retryable Errors {#non-retryable-errors} +### Non-Retryable Errors {/* #non-retryable-errors */} Non-Retryable Errors specify errors that shouldn't be retried. By default, none are specified. Errors are matched against the `type` field of the [Application Failure](/references/failures#application-failure). If one of those errors diff --git a/docs/encyclopedia/temporal-sdks.mdx b/docs/encyclopedia/temporal-sdks.mdx index 08fc66c408..267cd5a496 100644 --- a/docs/encyclopedia/temporal-sdks.mdx +++ b/docs/encyclopedia/temporal-sdks.mdx @@ -30,7 +30,7 @@ SDKs are more than just a development tool, however. The SDK APIs enable developers to write code in a particular pattern that mirrors real world processes. The SDK's internal implementation, working in collaboration with the Temporal Service, steps through that code, guaranteeing execution progression during application runtime. -## Temporal Applications {#temporal-application} +## Temporal Applications {/* #temporal-application */} A Temporal Application is the code you write, comprised of [Workflow Definitions](/workflow-definition), [Activity Definitions](/workflow-definition), code used to configure [Temporal Clients](#temporal-client), and code used to configure and start [Workers](/workers#worker). Developers create Temporal Applications using an [official Temporal SDK](#official-sdks). @@ -46,7 +46,7 @@ Additionally, a Temporal Workflow Execution is both resumable and recoverable, a Hence, a Temporal Application can run for seconds or years in the presence of arbitrary load and failures. -## Official SDKs {#official-sdks} +## Official SDKs {/* #official-sdks */} **What are the officially supported SDKs?** @@ -71,7 +71,7 @@ The following third-party SDKs exist but are not officially supported by Tempora - [Clojure](https://github.com/manetu/temporal-clojure-sdk) from [@Manetu](https://github.com/manetu) - [Scala](https://github.com/vitaliihonta/zio-temporal) from [@vitaliihonta](https://github.com/vitaliihonta) -## Why use a Temporal SDK? {#why-use-an-sdk} +## Why use a Temporal SDK? {/* #why-use-an-sdk */} Temporal SDKs empower developers to concentrate on creating dependable and scalable business logic, alleviating the need to build home-grown supervisor systems to ensure reliability and fault-tolerance. This is possible because the Temporal SDK provides a unified library that abstracts the intricacies of how Temporal handles distributed systems. @@ -143,7 +143,7 @@ This capability stems from the SDK's ability to persist each step the program ta {/* - [Developing for Durable Execution using the Go SDK](/develop/go/durable-execution) */} -## Temporal SDKs major components {#major-components} +## Temporal SDKs major components {/* #major-components */} **What are the major components of Temporal SDKs?** @@ -411,7 +411,7 @@ func LoanCreditCheckActivity(ctx context.Context, loanAmount int) (string, error } ``` -## The SDK and Temporal Service relationship {#sdk-and-cluster-relationship} +## The SDK and Temporal Service relationship {/* #sdk-and-cluster-relationship */} **How do the Temporal SDKs work with the Temporal Service?** diff --git a/docs/encyclopedia/temporal-service/archival.mdx b/docs/encyclopedia/temporal-service/archival.mdx index 991bae8d68..8ef1581566 100644 --- a/docs/encyclopedia/temporal-service/archival.mdx +++ b/docs/encyclopedia/temporal-service/archival.mdx @@ -15,7 +15,7 @@ tags: This page discusses [Archival](#archival). -## What is Archival? {#archival} +## What is Archival? {/* #archival */} Use Archival to copy closed Workflow Execution [Event Histories](/workflow-execution/event#event-history) and Visibility records from Temporal Service persistence to blob storage. diff --git a/docs/encyclopedia/temporal-service/multi-cluster-replication.mdx b/docs/encyclopedia/temporal-service/multi-cluster-replication.mdx index 28b79e393b..c4f46721ef 100644 --- a/docs/encyclopedia/temporal-service/multi-cluster-replication.mdx +++ b/docs/encyclopedia/temporal-service/multi-cluster-replication.mdx @@ -26,7 +26,7 @@ This page discusses the following: - [Zombie Workflows](#zombie-workflows) - [Workflow Task Processing](#workflow-task-processing) -## What is Multi-Cluster Replication? {#multi-cluster-replication} +## What is Multi-Cluster Replication? {/* #multi-cluster-replication */} Multi-Cluster Replication is a feature which asynchronously replicates Workflow Executions from active Clusters to other passive Clusters, for backup and state reconstruction. When necessary, for higher availability, Cluster operators can failover to any of the backup Clusters. diff --git a/docs/encyclopedia/temporal-service/persistence.mdx b/docs/encyclopedia/temporal-service/persistence.mdx index 62ef6a320c..2a638ce0fb 100644 --- a/docs/encyclopedia/temporal-service/persistence.mdx +++ b/docs/encyclopedia/temporal-service/persistence.mdx @@ -20,7 +20,7 @@ This page discusses the following: - [Persistence](#persistence) - [Dependency Versions](#dependency-versions) -## What is Persistence? {#persistence} +## What is Persistence? {/* #persistence */} The Temporal Persistence store is a database used by the [Temporal Server](/temporal-service/temporal-server) to persist events generated and processed in your Temporal Service and SDK. diff --git a/docs/encyclopedia/temporal-service/temporal-server.mdx b/docs/encyclopedia/temporal-service/temporal-server.mdx index 644fe48448..cb21a01952 100644 --- a/docs/encyclopedia/temporal-service/temporal-server.mdx +++ b/docs/encyclopedia/temporal-service/temporal-server.mdx @@ -29,7 +29,7 @@ This page discusses the following: - [Worker Service](#worker-service) - [Retention Period](#retention-period) -## What is the Temporal Server? {#temporal-server} +## What is the Temporal Server? {/* #temporal-server */} The Temporal Server consists of four independently scalable services: @@ -76,7 +76,7 @@ We offer maintenance support of **major** versions for at least 12 months after Temporal offers official support for, and is tested against, dependencies with the exact versions described in the `go.mod` file of the corresponding release tag. (For example, [v1.5.1](https://github.com/temporalio/temporal/tree/v1.5.1) dependencies are documented in [the go.mod for v1.5.1](https://github.com/temporalio/temporal/blob/v1.5.1/go.mod).) -## What is a Frontend Service? {#frontend-service} +## What is a Frontend Service? {/* #frontend-service */} The Frontend Service is a stateless gateway service that exposes a strongly typed [Proto API](https://github.com/temporalio/api/blob/master/temporal/api/workflowservice/v1/service.proto). The Frontend Service is responsible for rate limiting, authorizing, validating, and routing all inbound calls. @@ -107,7 +107,7 @@ The Frontend Service talks to the Matching Service, History Service, Worker Serv Ports are configurable in the Temporal Service configuration. -## What is a History Service? {#history-service} +## What is a History Service? {/* #history-service */} The History Service is responsible for persisting Workflow Execution state to the Event History. When the Workflow Execution is able to progress, the History Service adds a Task with the Workflow's updated history to the Task Queue. @@ -131,7 +131,7 @@ The History Service talks to the Matching Service and the database. Ports are configurable in the Temporal Service configuration. -### What is a History Shard? {#history-shard} +### What is a History Shard? {/* #history-shard */} A History Shard is an important unit within a Temporal Service by which concurrent Workflow Execution throughput can be scaled. @@ -161,7 +161,7 @@ Each History Shard maintains the Workflow Execution Event History, Workflow Exec (Relies on the experimental Multi-Cluster feature.) - Internal Visibility Task Queue: Pushes data to the [Advanced Visibility](/visibility#advanced-visibility) index. -## What is a Matching Service? {#matching-service} +## What is a Matching Service? {/* #matching-service */} The Matching Service is responsible for hosting user-facing [Task Queues](/task-queue) for Task dispatching. @@ -180,7 +180,7 @@ It talks to the Frontend Service, History Service, and the database. Ports are configurable in the Temporal Service configuration. -## What is a Worker Service? {#worker-service} +## What is a Worker Service? {/* #worker-service */} The Worker Service runs background processing for the replication queue, system Workflows, and (in versions older than 1.5.0) the Kafka visibility processor. @@ -203,7 +203,7 @@ It talks to the Frontend Service. Ports are configurable in the Temporal Service configuration. -## What is a Retention Period? {#retention-period} +## What is a Retention Period? {/* #retention-period */} Retention Period is the duration for which the Temporal Service stores data associated with closed Workflow Executions on a Namespace in the Persistence store. diff --git a/docs/encyclopedia/temporal-service/temporal-service-configuration.mdx b/docs/encyclopedia/temporal-service/temporal-service-configuration.mdx index 5fa5ab19d5..23a80e107d 100644 --- a/docs/encyclopedia/temporal-service/temporal-service-configuration.mdx +++ b/docs/encyclopedia/temporal-service/temporal-service-configuration.mdx @@ -20,7 +20,7 @@ This page discusses the following: - [Security Configuration](#temporal-cluster-security-configuration) - [Observability](#monitoring-and-observation) -## What is Temporal Service configuration? {#cluster-configuration} +## What is Temporal Service configuration? {/* #cluster-configuration */} Temporal Service configuration is the setup and configuration details of your self-hosted Temporal Service, defined using YAML. You must define your Temporal Service configuration when setting up your self-hosted Temporal Service. @@ -68,7 +68,7 @@ For details on dynamic configuration keys, see [Dynamic configuration reference] For dynamic configuration examples, see [https://github.com/temporalio/temporal/tree/master/config/dynamicconfig](https://github.com/temporalio/temporal/tree/master/config/dynamicconfig). -## What is Temporal Service security configuration? {#temporal-cluster-security-configuration} +## What is Temporal Service security configuration? {/* #temporal-cluster-security-configuration */} Secure your Temporal Service (self-hosted and Temporal Cloud) by encrypting your network communication and setting authentication and authorization protocols for API calls. @@ -128,7 +128,7 @@ Temporal offers two plugin interfaces for authentication and authorization of AP The logic of both plugins can be customized to fit a variety of use cases. When plugins are provided, the Frontend Service invokes their implementation before running the requested operation. -## What is Temporal Service observability? {#monitoring-and-observation} +## What is Temporal Service observability? {/* #monitoring-and-observation */} You can monitor and observe performance with metrics emitted by your self-hosted Temporal Service or by Temporal Cloud. diff --git a/docs/encyclopedia/temporal-service/visibility.mdx b/docs/encyclopedia/temporal-service/visibility.mdx index bb7498262b..ad900b6590 100644 --- a/docs/encyclopedia/temporal-service/visibility.mdx +++ b/docs/encyclopedia/temporal-service/visibility.mdx @@ -14,7 +14,7 @@ tags: This page discusses [Visibility](#visibility). -## What is Visibility? {#visibility} +## What is Visibility? {/* #visibility */} The term [Visibility](/visibility), within the Temporal Platform, refers to the subsystems and APIs that enable an operator to view, filter, and search for Workflow Executions that currently exist within a Temporal Service. diff --git a/docs/encyclopedia/temporal.mdx b/docs/encyclopedia/temporal.mdx index 5c0e3d5901..676699ddb5 100644 --- a/docs/encyclopedia/temporal.mdx +++ b/docs/encyclopedia/temporal.mdx @@ -31,7 +31,7 @@ The Temporal Platform handles these types of problems, allowing you to focus on title="The Temporal System" /> -## Durable Execution {#durable-execution} +## Durable Execution {/* #durable-execution */} Durable Execution in the context of Temporal refers to the ability of a Workflow Execution to maintain its state and progress even in the face of failures, crashes, or server outages. This is achieved through Temporal's use of an [Event History](/workflow-execution/event#event-history), which records the state of a Workflow Execution at each step. @@ -39,7 +39,7 @@ If a failure occurs, the Workflow Execution can resume from the last recorded ev This durability is a key feature of Temporal Workflow Executions, making them reliable and resilient. It enables application code to execute effectively once and to completion, regardless of whether it takes seconds or years. -## What is the Temporal Platform? {#temporal-platform} +## What is the Temporal Platform? {/* #temporal-platform */} The Temporal Platform consists of a [Temporal Service](/temporal-service) and [Worker Processes](/workers#worker-process). Together these components create a runtime for Workflow Executions. @@ -64,7 +64,7 @@ Worker Processes are hosted and operated by you and execute your code. Workers r width="90%" /> -## What is a Temporal Application? {#temporal-application} +## What is a Temporal Application? {/* #temporal-application */} A Temporal Application is a set of [Temporal Workflow Executions](/workflow-execution). Each Temporal Workflow Execution has exclusive access to its local state, executes concurrently to all other Workflow Executions, and communicates with other Workflow Executions and the environment via message passing. @@ -83,7 +83,7 @@ A Temporal Workflow Execution is a Reentrant Process. A Reentrant Process is re Therefore, a Temporal Workflow Execution executes a [Temporal Workflow Definition](/workflow-definition), also called a Temporal Workflow Function, your application code, exactly once and to completion—whether your code executes for seconds or years, in the presence of arbitrary load and arbitrary failures. -## What is a Failure? {#failure} +## What is a Failure? {/* #failure */} [Temporal Failures](/references/failures) are representations (in the SDKs and Event History) of various types of errors that occur in the system. diff --git a/docs/encyclopedia/visibility/dual-visibility.mdx b/docs/encyclopedia/visibility/dual-visibility.mdx index c3f59d450f..0c370c0c04 100644 --- a/docs/encyclopedia/visibility/dual-visibility.mdx +++ b/docs/encyclopedia/visibility/dual-visibility.mdx @@ -18,7 +18,7 @@ tags: This page discusses [Dual Visibility](#dual-visibility). -## What is Dual Visibility? {#dual-visibility} +## What is Dual Visibility? {/* #dual-visibility */} Dual Visibility is a feature that lets you set a secondary Visibility store in addition to a primary store in your Temporal Service. Setting up Dual Visibility is optional and can be used to [migrate your Visibility database](/self-hosted-guide/visibility#migrating-visibility-database) or create a backup Visibility store. diff --git a/docs/encyclopedia/visibility/list-filter.mdx b/docs/encyclopedia/visibility/list-filter.mdx index f7b4bffa97..2182e3842f 100644 --- a/docs/encyclopedia/visibility/list-filter.mdx +++ b/docs/encyclopedia/visibility/list-filter.mdx @@ -18,7 +18,7 @@ tags: This page discusses [List Filter](#list-filter). -## What is a List Filter? {#list-filter} +## What is a List Filter? {/* #list-filter */} The [Visibility](/temporal-service/visibility) List API requires you to provide a List Filter as an SQL-like string parameter. @@ -61,7 +61,7 @@ Both stored values and query strings are analyzed by the [Elasticsearch standard If you need exact matching on identifiers, UUIDs, or other structured strings, use `Keyword` instead. See [Choose a string type](/search-attribute#choose-a-string-type). -##### Tokenization {#text-tokenization} +##### Tokenization {/* #text-tokenization */} The standard analyzer applies [Unicode word boundary rules](https://unicode.org/reports/tr29/) to split values into tokens. All tokens are lowercased by the analyzer's lowercase filter. @@ -81,7 +81,7 @@ The following characters do **not** split when they appear between two letters o Dots and colons between digits also stay connected (`v1.2.3` → one token). However, a dot or colon between a digit and a letter does split: `v1.ProcessOrder` → `v1`, `processorder`. -##### Search matching {#text-search-matching} +##### Search matching {/* #text-search-matching */} The `=` operator on `Text` Search Attributes uses **OR matching**: the query string is tokenized using the same rules as above, and a result is returned if **any** query token matches **any** indexed token. diff --git a/docs/encyclopedia/visibility/search-attributes.mdx b/docs/encyclopedia/visibility/search-attributes.mdx index e79945f0e4..0431c8cc07 100644 --- a/docs/encyclopedia/visibility/search-attributes.mdx +++ b/docs/encyclopedia/visibility/search-attributes.mdx @@ -23,7 +23,7 @@ This page discusses the following: - [Default Search Attributes](#default-search-attribute) - [Custom Search Attributes](#custom-search-attribute) -## What is a Search Attribute? {#search-attribute} +## What is a Search Attribute? {/* #search-attribute */} A Search Attribute is an indexed field used in a [List Filter](/list-filter) to filter a list of [Workflow Executions](/workflow-execution) that have the Search Attribute in their metadata. @@ -56,7 +56,7 @@ For business logic in which you need to get information about a Workflow Executi If your business logic requires high throughput or low latency, store and fetch the data through Activities. You might experience lag due to time passing between the Workflow's state change and the Activity updating the Visibility store. -### Default Search Attributes {#default-search-attribute} +### Default Search Attributes {/* #default-search-attribute */} :::caution The `BinaryChecksums` and `BuildIds` Search Attributes are deprecated. They will stop being propagated for new Workflows starting in Temporal Server 1.32 and will be fully removed from query support in Temporal Server 1.34. @@ -125,7 +125,7 @@ You can use the default Search Attributes in a List Filter, such as in the Tempo - With advanced Visibility, you can combine default Search Attributes in a List Filter to get a list of specific Workflow Executions. For example: `temporal workflow list --query "WorkflowType = 'main.YourWorkflowDefinition' and ExecutionStatus != 'Running' and (StartTime > '2022-06-07T16:46:34.236-08:00' or CloseTime < '2022-06-08T16:46:34-08:00')"` -### Custom Search Attributes {#custom-search-attribute} +### Custom Search Attributes {/* #custom-search-attribute */} You can [create custom Search Attributes](/self-hosted-guide/visibility#create-custom-search-attributes) with unique key names that are relevant to your business needs. @@ -142,7 +142,7 @@ However, if using any of the [supported SQL databases](/self-hosted-guide/visibi See [custom Search Attributes limits](/search-attribute#custom-search-attribute-limits) for limits on the number and size of custom Search Attributes you can create. -#### Supported types {#supported-types} +#### Supported types {/* #supported-types */} Custom Search Attributes must be one of the following types: @@ -177,7 +177,7 @@ If you are storing lists in **Int** attributes, consider either migrating to **K - The **Text** type cannot be used in the "Order By" clause. -#### Choose a string type {#choose-a-string-type} +#### Choose a string type {/* #choose-a-string-type */} Temporal offers three string-based Search Attribute types. The right choice depends on what you store and how you need to search for it. @@ -203,7 +203,7 @@ Broader tokenizer and exact-matching improvements for `Text` Search Attributes a ::: -#### Custom Search Attributes limits {#custom-search-attribute-limits} +#### Custom Search Attributes limits {/* #custom-search-attribute-limits */} {/* TODO - [How to configure maximum number of Search Attribute keys per Cluster](#) */} @@ -244,7 +244,7 @@ This is configurable with [`SearchAttributesNumberOfKeysLimit`, `SearchAttribute For Temporal Cloud specific configurations, see the [Defaults, limits, and configurable settings -Temporal Cloud](/cloud/limits#number-of-custom-search-attributes) guide. -### Usage {#usage} +### Usage {/* #usage */} Search Attributes available in your Visibility store can be used with Workflow Executions for the Temporal Service. To actually have results from the use of a [List Filter](/list-filter), Search Attributes must be added to a Workflow Execution as metadata. diff --git a/docs/encyclopedia/visibility/visibility.mdx b/docs/encyclopedia/visibility/visibility.mdx index 801a26cd6b..6ef70bf009 100644 --- a/docs/encyclopedia/visibility/visibility.mdx +++ b/docs/encyclopedia/visibility/visibility.mdx @@ -26,7 +26,7 @@ The [Visibility store](/self-hosted-guide/visibility) in your Temporal Service s With Temporal Server v1.21, you can set up [Dual Visibility](/dual-visibility) to migrate your Visibility store from one database to another. -## Visibility features {#advanced-visibility} +## Visibility features {/* #advanced-visibility */} Visibility enables the listing, filtering, and sorting of [Workflow Executions](/workflow-execution) through a custom SQL-like [List Filter](/list-filter). @@ -52,7 +52,7 @@ The Count API returns approximate counts. ::: -## Legacy: standard Visibility {#standard-visibility} +## Legacy: standard Visibility {/* #standard-visibility */} Prior to Temporal Server v1.20, Temporal had two Visibility modes: "standard" and "advanced." Standard Visibility supported only predefined filters such as Workflow Type, Workflow Id, Run Id, and Execution Status, without custom Search Attributes. Advanced Visibility required Elasticsearch. diff --git a/docs/encyclopedia/workers/serverless-workers.mdx b/docs/encyclopedia/workers/serverless-workers.mdx index 16dc4a0fec..525d1220cd 100644 --- a/docs/encyclopedia/workers/serverless-workers.mdx +++ b/docs/encyclopedia/workers/serverless-workers.mdx @@ -39,7 +39,7 @@ This page covers the following: - [Constraints](#constraints) - [Compute providers](#compute-providers) -## What is a Serverless Worker? {#serverless-worker} +## What is a Serverless Worker? {/* #serverless-worker */} A Serverless Worker is a Temporal Worker that runs on serverless compute instead of a long-lived process. There is no always-on infrastructure to provision or scale. Temporal invokes the Worker when Tasks arrive on a Task Queue, and the @@ -55,14 +55,14 @@ Serverless Workers require [Worker Versioning](/worker-versioning). Each Serverl To deploy a Serverless Worker, see [Deploy a Serverless Worker](/production-deployment/worker-deployments/serverless-workers). -## How Serverless invocation works {#how-invocation-works} +## How Serverless invocation works {/* #how-invocation-works */} With long-lived Workers, you start the Worker process, which connects to Temporal and polls a Task Queue for work. Temporal does not need to know anything about the Worker's infrastructure. With Serverless Workers, Temporal starts the Worker. -### Worker Controller Instance {#worker-controller-instance} +### Worker Controller Instance {/* #worker-controller-instance */} The Worker Controller Instance (WCI) is a system Workflow that scales Serverless Workers based on Task Queue conditions. One WCI Workflow runs per Worker Deployment Version that has a compute provider configured. The WCI runs in the same @@ -113,14 +113,14 @@ The invocation flow works as follows: Each invocation is independent. The Worker creates a fresh client connection on every invocation. There is no connection reuse or shared state across invocations. -## Autoscaling {#autoscaling} +## Autoscaling {/* #autoscaling */} The [WCI](#worker-controller-instance) automatically scales Serverless Workers based on Task Queue signals. When Tasks arrive and no Worker is available, the WCI invokes new Workers. When the Tasks are done, Workers exit and scale to zero. The WCI uses two signals to decide when to invoke new Workers: -### Sync match failure {#sync-match-failure} +### Sync match failure {/* #sync-match-failure */} When a Task is submitted, the [Matching Service](/temporal-service/temporal-server#matching-service) attempts to route it directly to an available Worker. If no Worker is available, the sync match fails, and the Matching Service pushes a @@ -128,12 +128,12 @@ signal to the WCI. The WCI then invokes a new Worker. This is the primary scalin pushes match failures to the WCI as they happen rather than the WCI polling on a timer, latency stays low and scaling is responsive. -### Task Queue backlog {#task-queue-backlog} +### Task Queue backlog {/* #task-queue-backlog */} The WCI monitors Task Queue metadata to determine whether pending Tasks exist without enough Workers to process them. If there are Tasks on the queue and not enough Workers, the WCI invokes additional Workers. -## Scaling with long-lived Workers {#scaling-with-long-lived-workers} +## Scaling with long-lived Workers {/* #scaling-with-long-lived-workers */} Serverless Workers can share a Task Queue with long-lived Workers. Because Serverless Workers are only invoked on [sync match failure](#sync-match-failure), Serverless Workers only pick up Tasks that no long-lived Worker was available @@ -148,7 +148,7 @@ to unnecessary invocations and unpredictable scaling. ::: -## Worker lifecycle {#worker-lifecycle} +## Worker lifecycle {/* #worker-lifecycle */} A single Serverless Worker invocation has three phases: init, work, and shutdown. @@ -201,12 +201,12 @@ Raising only the Worker stop timeout does not make the Worker stop polling earli might terminate the Worker before the full stop timeout completes. In-flight Activities then do not get the full stop timeout to finish, and the shutdown hooks may not run. -## Failure handling {#failure-handling} +## Failure handling {/* #failure-handling */} Serverless Workers rely on Temporal's standard retry and timeout semantics to recover from failures. The following sections describe common failure scenarios and how they are handled. -### Worker crash {#worker-crash} +### Worker crash {/* #worker-crash */} If a Worker invocation crashes (out of memory, unhandled exception, etc.), the behavior follows standard Temporal retry semantics: @@ -215,7 +215,7 @@ semantics: - Temporal retries the Activity on a different Worker invocation. - No manual intervention is required. -### Provider concurrency limit {#provider-concurrency-limit} +### Provider concurrency limit {/* #provider-concurrency-limit */} If the compute provider's concurrency limit is reached (for example, AWS Lambda account concurrency): @@ -223,7 +223,7 @@ If the compute provider's concurrency limit is reached (for example, AWS Lambda - Tasks remain in the Task Queue backlog. No data loss occurs. - Processing slows until concurrency frees up. -### Resource exhaustion across Activity slots {#resource-exhaustion} +### Resource exhaustion across Activity slots {/* #resource-exhaustion */} By default, a single Worker invocation may run multiple Activity slots. A crash or resource exhaustion in one Activity (for example, out-of-memory from a memory-intensive operation) can affect other Activities running in the same @@ -236,7 +236,7 @@ To isolate Activities from each other: With single-slot configuration, each Activity gets a dedicated execution environment. -## Constraints {#constraints} +## Constraints {/* #constraints */} | Constraint | Detail | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | @@ -245,7 +245,7 @@ With single-slot configuration, each Activity gets a dedicated execution environ | Worker code | Same Temporal SDK Worker code, using the serverless Worker package for your SDK. | | Versioning | [Worker Versioning](/worker-versioning) is required. Each Workflow must have an `AutoUpgrade` or `Pinned` behavior, set per-Workflow or as a Worker-level default. | -## Compute providers {#compute-providers} +## Compute providers {/* #compute-providers */} A compute provider is the configuration that tells Temporal how to invoke a Serverless Worker. The compute provider is set on a [Worker Deployment Version](/worker-versioning#deployment-versions) and specifies the provider type, the diff --git a/docs/encyclopedia/workers/sticky-execution.mdx b/docs/encyclopedia/workers/sticky-execution.mdx index 9e89b2f68a..cb2488df07 100644 --- a/docs/encyclopedia/workers/sticky-execution.mdx +++ b/docs/encyclopedia/workers/sticky-execution.mdx @@ -13,7 +13,7 @@ tags: This page discusses [Sticky Execution](#sticky-execution). -## What is a Sticky Execution? {#sticky-execution} +## What is a Sticky Execution? {/* #sticky-execution */} Workers cache the state of the Workflow they execute. To make this caching more effective, Temporal employs a performance optimization known as "Sticky Execution", which directs Workflow Tasks to the same Worker that previously processed tasks for a specific Workflow Execution. diff --git a/docs/encyclopedia/workers/task-queues.mdx b/docs/encyclopedia/workers/task-queues.mdx index 67cdec4863..95a0d2c99f 100644 --- a/docs/encyclopedia/workers/task-queues.mdx +++ b/docs/encyclopedia/workers/task-queues.mdx @@ -16,7 +16,7 @@ import { CaptionedImage } from '@site/src/components'; This page discusses [Task Queues](#task-queue) including [where to set Task Queues](#set-task-queue) and [Task Ordering](#task-ordering). -## What is a Task Queue? {#task-queue} +## What is a Task Queue? {/* #task-queue */} A Task Queue is a lightweight, dynamically allocated queue that one or more [Worker Entities](/workers#worker-entity) poll for [Tasks](/tasks). There are three types of Task Queues: Activity Task Queues, Workflow Task Queues, and Nexus Task Queues. @@ -72,7 +72,7 @@ When Workers don't have a registered Workflow, Activity, Nexus Operation, or dyn - "Not Found" Workflow Tasks and Activity Tasks are treated as _retryable_ errors. - "Not Found" Nexus Operation handlers are _non-retryable_ and must be manually retried from the caller Workflow. -#### Where to set Task Queues {#set-task-queue} +#### Where to set Task Queues {/* #set-task-queue */} There are five places where the name of the Task Queue can be set by the developer. diff --git a/docs/encyclopedia/workers/task-routing-worker-sessions.mdx b/docs/encyclopedia/workers/task-routing-worker-sessions.mdx index 9202af7f01..0c460d6ca9 100644 --- a/docs/encyclopedia/workers/task-routing-worker-sessions.mdx +++ b/docs/encyclopedia/workers/task-routing-worker-sessions.mdx @@ -18,7 +18,7 @@ This page discusses the following: - [Task Routing](#task-routing) - [Worker Sessions](#worker-session) -## What is Task Routing? {#task-routing} +## What is Task Routing? {/* #task-routing */} Task Routing is simply when a Task Queue is paired with one or more Workers, primarily for Activity Task Executions. @@ -97,7 +97,7 @@ If you have a new backward-incompatible Activity Definition, start by using a di Alternatively, you can use [Worker Versioning](/worker-versioning), which lets you tag Workers with a version and route Workflow and Activity Tasks to specific versions without requiring separate Task Queues. Worker Versioning supports both Pinned Workflows (which complete on a single Worker Deployment Version) and Auto-Upgrade Workflows (which automatically move to the latest version). -## What is a Worker Session? {#worker-session} +## What is a Worker Session? {/* #worker-session */} A Worker Session is a feature provided by some SDKs that provides a straightforward API for [Task Routing](#task-routing) to ensure that Activity Tasks are executed with the same Worker without requiring you to manually specify Task Queue names. It also includes features like concurrent session limitations and Worker failure detection. diff --git a/docs/encyclopedia/workers/tasks.mdx b/docs/encyclopedia/workers/tasks.mdx index f6263c69a1..bbfc976674 100644 --- a/docs/encyclopedia/workers/tasks.mdx +++ b/docs/encyclopedia/workers/tasks.mdx @@ -30,7 +30,7 @@ This page discusses the following: - [Nexus Task](#nexus-task) - [Nexus Task Execution](#nexus-task-execution) -## What is a Task? {#task} +## What is a Task? {/* #task */} A Task is a unit of work for [Workers](/workers). The Temporal Service places Tasks on [Task Queues](/task-queue), and Workers poll for and process them to advance [Workflows](/workflows), run [Activity](/activities) attempts, or handle @@ -42,11 +42,11 @@ There are three types of Tasks: - [Activity Task](#activity-task) - [Nexus Task](#nexus-task) -## What is a Workflow Task? {#workflow-task} +## What is a Workflow Task? {/* #workflow-task */} A Workflow Task advances a [Workflow Execution](/workflow-execution) by one step. -### When are Workflow Tasks scheduled? {#when-workflow-tasks-scheduled} +### When are Workflow Tasks scheduled? {/* #when-workflow-tasks-scheduled */} The Temporal Service creates and schedules a new Workflow Task whenever one of the following occurs: @@ -61,7 +61,7 @@ The Temporal Service creates and schedules a new Workflow Task whenever one of t Any event that might affect the Workflow's state triggers a new Workflow Task. The Workflow Task bundles together all new events that have occurred since the last Workflow Task completed. -### How does a Worker process a Workflow Task? {#how-worker-processes-workflow-task} +### How does a Worker process a Workflow Task? {/* #how-worker-processes-workflow-task */} When a Worker picks up a Workflow Task, it replays the entire Workflow Execution from the beginning using the Event History. @@ -79,7 +79,7 @@ History. This replay mechanism makes Temporal Workflows durable and fault-tolerant. If a Worker crashes mid-execution, another Worker can pick up the Workflow Task and replay the entire history to reconstruct the exact state before continuing -### What is a Workflow Task Execution? {#workflow-task-execution} +### What is a Workflow Task Execution? {/* #workflow-task-execution */} A Workflow Task Execution occurs when a [Worker](/workers#worker-entity) picks up a [Workflow Task](#workflow-task) and uses it to make progress on the execution of a [Workflow Definition](/workflow-definition) (also known as a Workflow @@ -89,7 +89,7 @@ Workflow Task Execution is typically very fast (milliseconds). The Worker replay Event History. No actual I/O operations occur during replay (Activity results come from history). The time spent in a Workflow Task is unrelated to how long Activities or Timers take. -## Workflow Task Failures vs Workflow Execution Failures {#workflow-task-failures-vs-execution-failures} +## Workflow Task Failures vs Workflow Execution Failures {/* #workflow-task-failures-vs-execution-failures */} Understanding the difference between Workflow Task failures and Workflow Execution failures is essential to working with Temporal at a deeper level. @@ -124,11 +124,11 @@ and the executions stay Open and retry. After deploying a fix, the Workflows aut **Workflow Execution failure example:** A payment Activity fails due to a declined card, the failure propagates uncaught, and the Workflow closes as Failed. The customer updates payment details and restarts the order. -## What is an Activity Task? {#activity-task} +## What is an Activity Task? {/* #activity-task */} An Activity Task runs one attempt of an [Activity](/activities). -### What is an Activity Task Execution? {#activity-task-execution} +### What is an Activity Task Execution? {/* #activity-task-execution */} An Activity Task Execution occurs when a [Worker](/workers#worker-entity) uses the context provided from the [Activity Task](#activity-task) and executes the [Activity Definition](/activity-definition) (also known as the Activity @@ -158,11 +158,11 @@ Once an Activity Task finishes execution, the Worker responds to the Temporal Se - ActivityTaskTerminated - ActivityTaskTimedOut -## What is a Nexus Task? {#nexus-task} +## What is a Nexus Task? {/* #nexus-task */} A Nexus Task delivers one Nexus request to start or cancel a [Nexus Operation](/nexus). -### What is a Nexus Task Execution? {#nexus-task-execution} +### 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 its Nexus Operation handler diff --git a/docs/encyclopedia/workers/worker-versioning.mdx b/docs/encyclopedia/workers/worker-versioning.mdx index f62ea2a5e1..e9fa65bd49 100644 --- a/docs/encyclopedia/workers/worker-versioning.mdx +++ b/docs/encyclopedia/workers/worker-versioning.mdx @@ -26,12 +26,12 @@ This page defines some of the underlying concepts used in [Worker Versioning](/p - [Versioning Statuses](#versioning-statuses) - [Continue-as-new, Child Workflow, and Retry Semantics](#inheritance-semantics) -## Worker Deployments {#deployments} +## Worker Deployments {/* #deployments */} A Worker Deployment is a logical service that groups similar Workers together for unified management. Each Deployment has a name (such as your service name) and supports versioning through a series of Worker Deployment Versions. -## Worker Deployment Versions {#deployment-versions} +## Worker Deployment Versions {/* #deployment-versions */} A Worker Deployment Version represents an iteration of a Worker Deployment. Each Deployment Version is identified by a deployment name and a Build ID. @@ -39,17 +39,17 @@ The deployment name groups related Workers across versions, and the Build ID ide Each Deployment Version consists of Workers that share the same code build and environment. When a Worker starts polling for Workflow and Activity Tasks, it reports its Deployment Version to the Temporal Server. -## Versioning Behaviors {#versioning-behaviors} +## Versioning Behaviors {/* #versioning-behaviors */} You can declare each Workflow type to have a **Versioning Behavior**, either Pinned or Auto-Upgrade, in your Workflow configuration using an SDK or the CLI. To learn more about implementing Worker Versioning, see our [Worker Versioning in production](production-deployment/worker-deployments/worker-versioning) page. -### Pinned Workflows {#pinned} +### Pinned Workflows {/* #pinned */} A **Pinned** Workflow is guaranteed to complete on a single Worker Deployment Version. You can mark a Workflow Type as pinned when you register it by adding an additional Pinned parameter. If you need to move a pinned Workflow to a new version, use [`temporal workflow update-options`](/cli/workflow#update-options). -### Auto-Upgrade Workflows {#auto-upgrade} +### Auto-Upgrade Workflows {/* #auto-upgrade */} 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). @@ -78,7 +78,7 @@ Since Independent Activities aren't part of a Workflow's version, they can run i - **Ramping Worker Deployment Version**: The version where a configurable percentage of Workflows are routed to unless they were previously pinned on a different version. The ramp percentage can be in the range [0, 100]. Workflows that don't go to the Ramping Version will go to the Current Version. If no Ramping Version is specified, 100% of new Workflows and Auto-Upgrade Workflows will go to the Current Version. - **Target Worker Deployment Version**: The version your Workflow will upgrade to next. This could be the Deployment's Current Version or the Ramping Version. For example, if an Auto-Upgrade Workflow was running on Version A, the Current Version is B, and there is a 5% ramp to C, there is a 95% chance that its Target Version is B and 5% that it's C. Workflow ID determines whether the workflow falls into the 95% group or the 5% group. -## Versioning Statuses {#versioning-statuses} +## Versioning Statuses {/* #versioning-statuses */} A Worker Deployment Version moves through the following states: @@ -87,7 +87,7 @@ A Worker Deployment Version moves through the following states: 3. **Draining**: The version has open pinned Workflows running on it, but stopped being Current or Ramping, usually because a newer version has been deployed. It is possible to be Draining and have no open pinned Workflows for a short time, since the drainage status is updated only periodically. 4. **Drained**: The version was draining and now all the pinned Workflows that were running on it are closed. Closed Workflows may still re-run some code paths if they are [Queried](https://docs.temporal.io/sending-messages#sending-queries) within their [Retention Period](https://docs.temporal.io/temporal-service/temporal-server#retention-period) and Workers with that version are still polling. -## Continue-as-new, Child Workflow, and Retry Semantics {#inheritance-semantics} +## Continue-as-new, Child Workflow, and Retry Semantics {/* #inheritance-semantics */} When Workflows start new runs (e.g. by continuing-as-new or retrying) the new run may inherit their versioning behavior. This section explains how inheritance works across different Workflow execution patterns. diff --git a/docs/encyclopedia/workers/workers.mdx b/docs/encyclopedia/workers/workers.mdx index b136ab7159..1be978cac0 100644 --- a/docs/encyclopedia/workers/workers.mdx +++ b/docs/encyclopedia/workers/workers.mdx @@ -23,12 +23,12 @@ This page discusses the following: - [Worker Identity](#worker-identity) - [Worker Process](#worker-process) -## What is a Worker? {#worker} +## What is a Worker? {/* #worker */} In day-to-day conversations, the term Worker is used to denote either a [Worker Program](#worker-program), a [Worker Process](#worker-process), or a [Worker Entity](/workers#worker-entity). Temporal documentation aims to be explicit and differentiate between them. -## What is a Worker Program? {#worker-program} +## What is a Worker Program? {/* #worker-program */} A Worker Program is the static code that defines the constraints of the Worker Process, developed using the APIs of a Temporal SDK. @@ -46,7 +46,7 @@ A Worker Program is the static code that defines the constraints of the Worker P ::: -## What is a Worker Entity? {#worker-entity} +## What is a Worker Entity? {/* #worker-entity */} A Worker Entity is the individual Worker within a Worker Process that listens to a specific Task Queue. @@ -67,7 +67,7 @@ Therefore, a single Worker can handle millions of open Workflow Executions, assu - [How to tune Workers](/develop/worker-performance) - [Worker tuning quick reference](/develop/worker-tuning-reference) - SDK defaults and metrics -## What is a Worker Identity? {#worker-identity} +## What is a Worker Identity? {/* #worker-identity */} Workers have an associated identifier that helps identify the specific Worker instance. By default, Temporal SDKs set a Worker Identity to `${process.pid}@${os.hostname()}`, which combines the Worker's process ID (`process.pid`) and the hostname of the machine running the Worker (`os.hostname()`). @@ -98,7 +98,7 @@ Here are some approaches: - **Ensure uniqueness**: Make sure that the Worker Identity is unique within your system to avoid ambiguity when debugging issues. - **Keep it concise**: While including relevant information is important, try to keep the Worker Identity concise and easily readable to facilitate quick identification and troubleshooting. -## What is a Worker Process? {#worker-process} +## What is a Worker Process? {/* #worker-process */} -### Update Validators {#update-validators} +### Update Validators {/* #update-validators */} When you define an Update handler, you may optionally define an Update Validator: a read operation that's responsible for accepting or rejecting the Update. You can use Validators to verify arguments or make sure the Workflow is ready to accept your Updates. @@ -166,7 +166,7 @@ Once the Update handler is finished and has returned a value, the operation is c -### Exceptions in message handlers {#exceptions} +### Exceptions in message handlers {/* #exceptions */} When throwing an exception in a message handler, you should decide whether to make it an [Application Failure](/references/failures#application-failure). The implications are different between Signals and Updates. @@ -197,7 +197,7 @@ If you throw any other exception, by default, it will cause a [Workflow Task Fai In Go, returning an error behaves like an [Application Failure](/references/failures#application-failure) in the other SDKs. Panics behave like non-Application Failure exceptions in other languages, in that they cause a [Workflow Task Failure](/references/failures#workflow-task-failures). -### Writing Signal Handlers {#writing-signal-handlers} +### Writing Signal Handlers {/* #writing-signal-handlers */} Use these links to see a simple Signal handler. @@ -212,7 +212,7 @@ Use these links to see a simple Signal handler. -### Writing Update Handlers {#writing-update-handlers} +### Writing Update Handlers {/* #writing-update-handlers */} Use these links to see a simple update handler. @@ -227,7 +227,7 @@ Use these links to see a simple update handler. -### Writing Query Handlers {#writing-query-handlers} +### Writing Query Handlers {/* #writing-query-handlers */} Author queries using these per-language guides. diff --git a/docs/encyclopedia/workflow-message-passing/sending-messages.mdx b/docs/encyclopedia/workflow-message-passing/sending-messages.mdx index 36cedaa9bc..fe7a700071 100644 --- a/docs/encyclopedia/workflow-message-passing/sending-messages.mdx +++ b/docs/encyclopedia/workflow-message-passing/sending-messages.mdx @@ -38,7 +38,7 @@ This section will help you write clients that send messages to Workflows which i - [Sending Updates](#sending-updates) - [Sending Queries](#sending-queries) -### Sending Signals {#sending-signals} +### Sending Signals {/* #sending-signals */} You can send Signals from any Temporal Client, the Temporal CLI, or you can Signal one Workflow to another. @@ -71,7 +71,7 @@ You can also Signal-With-Start to lazily initialize a Workflow while sending a S -#### Signal-With-Start {#signal-with-start} +#### Signal-With-Start {/* #signal-with-start */} Signal-With-Start is a great tool for lazily initializing Workflows. When you send this operation, if there is a running Workflow Execution with the given Workflow Id, it will be Signaled. Otherwise, a new Workflow Execution starts and is immediately sent the Signal. @@ -86,7 +86,7 @@ Signal-With-Start is a great tool for lazily initializing Workflows. When you se -### Sending Updates {#sending-updates} +### Sending Updates {/* #sending-updates */} :::note @@ -130,7 +130,7 @@ Use [Update Validators](/handling-messages#update-validators) and [Update IDs](/ -#### Update-With-Start {#update-with-start} +#### Update-With-Start {/* #update-with-start */} :::tip @@ -180,7 +180,7 @@ The SDKs will retry the Update-With-Start request, but there is no guarantee tha -### Sending Queries {#sending-queries} +### Sending Queries {/* #sending-queries */} Queries can be sent from a Temporal Client or the Temporal CLI to a Workflow Execution--even if this Workflow has Completed. This call is synchronous and will call into the corresponding Query handler. You can also send a built-in "Stack Trace Query" for debugging. @@ -197,7 +197,7 @@ You can also send a built-in "Stack Trace Query" for debugging. -#### Stack Trace Query {#stack-trace-query} +#### Stack Trace Query {/* #stack-trace-query */} In many SDKs, the Temporal Client exposes a predefined `__stack_trace` Query that returns the call stack of all the threads owned by that Workflow Execution. This is a great way to troubleshoot a Workflow Execution in production. diff --git a/docs/encyclopedia/workflow-message-passing/workflow-message-passing.mdx b/docs/encyclopedia/workflow-message-passing/workflow-message-passing.mdx index 4dbfefe881..4eb5a542d6 100644 --- a/docs/encyclopedia/workflow-message-passing/workflow-message-passing.mdx +++ b/docs/encyclopedia/workflow-message-passing/workflow-message-passing.mdx @@ -41,7 +41,7 @@ Temporal supports three types of messages: Signals, Queries, and Updates: - Updates are synchronous, tracked write requests. The sender of the Update can wait for a response on completion or an error on failure. -## How to choose between Signals, Updates, and Queries as a Workflow author? {#choosing-messages} +## How to choose between Signals, Updates, and Queries as a Workflow author? {/* #choosing-messages */} This section will help you write Workflows that receive messages. diff --git a/docs/encyclopedia/workflow/cron-job.mdx b/docs/encyclopedia/workflow/cron-job.mdx index deb04e7fe1..5852157470 100644 --- a/docs/encyclopedia/workflow/cron-job.mdx +++ b/docs/encyclopedia/workflow/cron-job.mdx @@ -17,7 +17,7 @@ This page discusses [Cron Job](#temporal-cron-job) including [Cron Schedules](#c import { CaptionedImage } from '@site/src/components'; -## What is a Temporal Cron Job? {#temporal-cron-job} +## What is a Temporal Cron Job? {/* #temporal-cron-job */} :::note @@ -63,7 +63,7 @@ The Cron Schedule runs until the Workflow Execution Timeout is reached or you te src="/diagrams/temporal-cron-job-failure-with-retry.svg" title="Temporal Cron Job Run Failure with a Retry Policy" /> -## Cron Schedules {#cron-schedules} +## Cron Schedules {/* #cron-schedules */} Cron Schedules are interpreted in UTC time by default. @@ -109,7 +109,7 @@ Intervals just take a string that can be accepted by [time.ParseDuration](http:/ @every ``` -## Time zones {#cron-job-time-zones} +## Time zones {/* #cron-job-time-zones */} _This feature only applies in Temporal 1.15 and up_ @@ -127,7 +127,7 @@ If you need to use time zones, here are a few edge cases to keep in mind: - **Updating Temporal:** If you use the official Docker images, note that an upgrade of the Temporal Service may include an update to the tzdata files, which may change the meaning of your Cron Schedule. You should be aware of upcoming changes to the definitions of the time zones you use, particularly around daylight saving time start/end dates. - **Absolute Time Fixed at Start:** The absolute start time of the next Run is computed and stored in the database when the previous Run completes, and is not recomputed. This means that if you have a Cron Schedule that runs very infrequently, and the definition of the time zone changes between one Run and the next, the Run might happen at the wrong time. For example, `CRON_TZ=America/Los_Angeles 0 12 11 11 *` means "noon in Los Angeles on November 11" (normally not in DST). If at some point the government makes any changes (for example, move the end of DST one week later, or stay on permanent DST year-round), the meaning of that specification changes. In that first year, the Run happens at the wrong time, because it was computed using the older definition. -## How to stop a Temporal Cron Job {#stop-cron-schedules} +## How to stop a Temporal Cron Job {/* #stop-cron-schedules */} A Temporal Cron Job does not stop spawning Runs until it has been Terminated or until the [Workflow Execution Timeout](/encyclopedia/detecting-workflow-failures#workflow-execution-timeout) is reached. diff --git a/docs/encyclopedia/workflow/dynamic-handler.mdx b/docs/encyclopedia/workflow/dynamic-handler.mdx index c5c2cdb652..942b86d65e 100644 --- a/docs/encyclopedia/workflow/dynamic-handler.mdx +++ b/docs/encyclopedia/workflow/dynamic-handler.mdx @@ -15,7 +15,7 @@ tags: This page discusses [Dynamic Handler](#dynamic-handler). -## What is a Dynamic Handler? {#dynamic-handler} +## What is a Dynamic Handler? {/* #dynamic-handler */} Temporal supports Dynamic Workflows, Activities, Signals, and Queries. diff --git a/docs/encyclopedia/workflow/patching.mdx b/docs/encyclopedia/workflow/patching.mdx index 2a6e9e3889..2989699d94 100644 --- a/docs/encyclopedia/workflow/patching.mdx +++ b/docs/encyclopedia/workflow/patching.mdx @@ -15,7 +15,7 @@ tags: This page discusses [Patching](#patching). -## What is Patching? {#patching} +## What is Patching? {/* #patching */} A Patch defines a logical branch in a Workflow for a specific change, similar to a feature flag. It applies a code change to new Workflow Executions while avoiding disruptive changes to in-progress Workflow Executions. diff --git a/docs/encyclopedia/workflow/schedule.mdx b/docs/encyclopedia/workflow/schedule.mdx index ada92a7955..97a9c3c916 100644 --- a/docs/encyclopedia/workflow/schedule.mdx +++ b/docs/encyclopedia/workflow/schedule.mdx @@ -15,7 +15,7 @@ tags: This page discusses [Schedule](#schedule). -## What is a Schedule? {#schedule} +## What is a Schedule? {/* #schedule */} A Schedule contains instructions for starting a [Workflow Execution](/workflow-execution) at specific times. Schedules provide a more flexible and user-friendly approach than [Temporal Cron Jobs](/cron-job). diff --git a/docs/encyclopedia/workflow/workflow-definition.mdx b/docs/encyclopedia/workflow/workflow-definition.mdx index 0e9a6c436b..8b9cb7380a 100644 --- a/docs/encyclopedia/workflow/workflow-definition.mdx +++ b/docs/encyclopedia/workflow/workflow-definition.mdx @@ -32,7 +32,7 @@ With Temporal, those steps are defined by writing code, known as a Workflow Defi In day-to-day conversations, the term _Workflow_ might refer to [Workflow Type](#workflow-type), a [Workflow Definition](/workflow-definition), or a [Workflow Execution](/workflow-execution). Temporal documentation aims to be explicit and differentiate between them. -## What is a Workflow Definition? {#workflow-definition} +## What is a Workflow Definition? {/* #workflow-definition */} A Workflow Definition is the code that defines the Workflow. It is written with a programming language and corresponding Temporal SDK. @@ -183,7 +183,7 @@ A Workflow Execution effectively executes once to completion, while a Workflow F We strongly recommend that you write a Workflow Definition in a language that has a corresponding Temporal SDK. -### Deterministic constraints {#deterministic-constraints} +### Deterministic constraints {/* #deterministic-constraints */} A critical aspect of developing Workflow Definitions is ensuring that they are deterministic. Generally speaking, this means you must take care to ensure that any time your Workflow code is executed it makes the same Workflow API calls in the same sequence, given the same input. @@ -235,7 +235,7 @@ The following are the two reasons why a Command might be generated out of sequen 1. Code changes are made to a Workflow Definition that is in use by a running Workflow Execution. 2. There is intrinsic non-deterministic logic (such as inline random branching). -### Code changes can cause non-deterministic behavior {#non-deterministic-change} +### Code changes can cause non-deterministic behavior {/* #non-deterministic-change */} The Workflow Definition can change in very limited ways once there is a Workflow Execution depending on it. To alleviate non-deterministic issues that arise from code changes, we recommend using [Workflow Versioning](#workflow-versioning). @@ -271,7 +271,7 @@ The following are examples of minor changes that would not result in non-determi - Call to Signal an External Workflow Execution. - Adding a Signal Handler for a Signal Type that has not been sent to this Workflow Execution. -### Intrinsic non-deterministic logic {#intrinsic-nondeterministic-logic} +### Intrinsic non-deterministic logic {/* #intrinsic-nondeterministic-logic */} Intrinsic non-determinism is when a Workflow Function Execution might emit a different sequence of Commands on re-execution, regardless of whether all the input parameters are the same. @@ -303,7 +303,7 @@ For SDK-specific replay-safe APIs and examples (logging, random numbers, time, r - [Ruby: Workflow Logic Requirements](/develop/ruby/workflows/basics#workflow-logic-requirements) - [Rust: Workflow Logic Requirements](/develop/rust/workflows/basics#workflow-logic-requirements) -### Versioning Workflows {#workflow-versioning} +### Versioning Workflows {/* #workflow-versioning */} The Temporal Platform requires that Workflow code (Workflow Definitions) be deterministic in nature. This requirement means that developers should consider how they plan to handle changes to Workflow code over time. @@ -322,11 +322,11 @@ Support for the experimental method of Worker Versioning prior to 2025 will be r You can use either strategy, or a combination. -#### Worker Versioning {#worker-versioning} +#### Worker Versioning {/* #worker-versioning */} This is the **recommended** way to handle versioning and users see improved error rates when adopting it. To learn more about Worker Versioning, see our [Worker Versioning in production](production-deployment/worker-deployments/worker-versioning) page. -#### Versioning with Patching {#workflow-patching} +#### Versioning with Patching {/* #workflow-patching */} When keeping Workflows compatible, you should patch and ideally how to test your running Workflows will be safe to run on a new code version. @@ -341,7 +341,7 @@ To patch: To test, see [Safe Deployments](/develop/safe-deployments.mdx). -### Handling unreliable Worker Processes {#unreliable-worker-processes} +### Handling unreliable Worker Processes {/* #unreliable-worker-processes */} You do not handle Worker Process failure or restarts in a Workflow Definition. @@ -349,7 +349,7 @@ Workflow Function Executions are completely oblivious to the Worker Process in t The Temporal Platform ensures that the state of a Workflow Execution is recovered and progress resumes if there is an outage of either Worker Processes or the Temporal Service itself. The only reason a Workflow Execution might fail is due to the code throwing an error or exception, not because of underlying infrastructure outages. -### What is a Workflow Type? {#workflow-type} +### What is a Workflow Type? {/* #workflow-type */} A Workflow Type is a name that maps to a Workflow Definition. diff --git a/docs/encyclopedia/workflow/workflow-execution/continue-as-new.mdx b/docs/encyclopedia/workflow/workflow-execution/continue-as-new.mdx index 393e810ea4..de14c7e953 100644 --- a/docs/encyclopedia/workflow/workflow-execution/continue-as-new.mdx +++ b/docs/encyclopedia/workflow/workflow-execution/continue-as-new.mdx @@ -15,7 +15,7 @@ tags: This page discusses [Continue-As-New](#continue-as-new) and how to decide [when to use it](#when). -## What is Continue-As-New? {#continue-as-new} +## What is Continue-As-New? {/* #continue-as-new */} Continue-As-New allows you to checkpoint your Workflow's state and start a fresh Workflow. @@ -45,7 +45,7 @@ Workflows that do this are often called Entity Workflows because they represent - [How to Continue-As-New using the Ruby SDK](/develop/ruby/workflows/continue-as-new) - [How to Continue-As-New using the Rust SDK](/develop/rust/workflows/continue-as-new) -## When in your Workflow is it right to Continue-As-New? {#when} +## When in your Workflow is it right to Continue-As-New? {/* #when */} Temporal will tell your Workflow when it's approaching performance or scalability problems. Find out if it's time by checking Continue-As-New Suggested in your Workflow at spots in your implementation where you are ready to checkpoint your state. diff --git a/docs/encyclopedia/workflow/workflow-execution/event.mdx b/docs/encyclopedia/workflow/workflow-execution/event.mdx index 8093cc0440..100ce374cd 100644 --- a/docs/encyclopedia/workflow/workflow-execution/event.mdx +++ b/docs/encyclopedia/workflow/workflow-execution/event.mdx @@ -30,7 +30,7 @@ The Temporal Service tracks the progress of each Workflow Execution by appending This information not only enables developers to know what took place, but is also essential for providing Durable Execution, since it enables the Workflow Execution to recover from a crash and continue making progress. In order to maintain high performance, the Temporal Service places limits on both the number and size of items in the Event History for each Workflow Execution. -## What is an Event? {#event} +## What is an Event? {/* #event */} Events are created by the Temporal Service in response to external occurrences and Commands generated by a Workflow Execution. Each Event corresponds to an `enum` that is defined in the [Server API](https://github.com/temporalio/api/blob/master/temporal/api/enums/v1/event_type.proto). @@ -39,7 +39,7 @@ All Events are recorded in the [Event History](#event-history). A list of all possible Events that could appear in a Workflow Execution Event History is provided in the [Event reference](/references/events). -### Activity Events {#activity-events} +### Activity Events {/* #activity-events */} Seven Activity-related Events are added to Event History at various points in an Activity Execution: @@ -59,14 +59,14 @@ While the Activity is running and retrying, [ActivityTaskScheduled](/references/ ::: -### What is an Event History? {#event-history} +### What is an Event History? {/* #event-history */} An append-only log of [Events](#event) for your application. - Event History is durably persisted by the Temporal service, enabling seamless recovery of your application state from crashes or failures. - It also serves as an audit log for debugging. -### Event History limits {#event-history-limits} +### Event History limits {/* #event-history-limits */} The Temporal Service stores the complete Event History for the entire lifecycle of a Workflow Execution. @@ -80,7 +80,7 @@ The Workflow Execution is terminated when the Event History: To avoid hitting these limits, you can use the [Continue-As-New](/workflow-execution/continue-as-new) feature to close the current Workflow Execution and create a new one. -### Event loop {#event-loop} +### Event loop {/* #event-loop */} A Workflow Execution is made up of a sequence of [Events](#event) called an [Event History](#event-history). Events are created by the Temporal Service in response to either Commands or actions requested by a Temporal Client (such as a request to spawn a Workflow Execution). @@ -89,7 +89,7 @@ Events are created by the Temporal Service in response to either Commands or act src="/diagrams/workflow-execution-swim-lane-01.svg" title="Workflow Execution" /> -## Time constraints {#time-constraints} +## Time constraints {/* #time-constraints */} **Is there a limit to how long Workflows can run?** @@ -101,14 +101,14 @@ It can also hit [Workflow Versioning](/workflow-definition#workflow-versioning) For these reasons, it can be a good idea to [Continue-As-New](/workflow-execution/continue-as-new) periodically. -## What is a Reset? {#reset} +## What is a Reset? {/* #reset */} A Reset terminates a [Workflow Execution](/workflow-execution) and creates a new Workflow Execution with the same [Workflow Type](/workflow-definition#workflow-type) and [Workflow ID](/workflow-execution/workflowid-runid). The [Event History](/workflow-execution/event#event-history) is copied from the original execution up to and including the reset point. The new execution continues from the reset point. Valid reset points are: `WorkflowTaskStarted`, `WorkflowTaskCompleted`, `WorkflowTaskTimedOut`, and `WorkflowTaskFailed`. Signals in the original history can be optionally copied to the new history, whether they appear after the reset point or not. -## What is a Side Effect? {#side-effect} +## What is a Side Effect? {/* #side-effect */} :::note @@ -125,7 +125,7 @@ A Side Effect does not re-execute upon replay, but instead returns the recorded Do not ever have a Side Effect that could fail, because failure could result in the Side Effect function executing more than once. If there is any chance that the code provided to the Side Effect could fail, use an Activity. -## What is a Principal Attribution? {#principal-attribution} +## What is a Principal Attribution? {/* #principal-attribution */} :::tip SUPPORT, STABILITY, and DEPENDENCY INFO diff --git a/docs/encyclopedia/workflow/workflow-execution/limits.mdx b/docs/encyclopedia/workflow/workflow-execution/limits.mdx index 642182c403..ffb5f6745d 100644 --- a/docs/encyclopedia/workflow/workflow-execution/limits.mdx +++ b/docs/encyclopedia/workflow/workflow-execution/limits.mdx @@ -16,7 +16,7 @@ tags: This page discusses [Workflow Execution limits](#workflow-execution-limits), [Workflow Execution Callback limits](#workflow-execution-callback-limits), and [Nexus Operation limits](#workflow-execution-nexus-operation-limits). -## Limits {#workflow-execution-limits} +## Limits {/* #workflow-execution-limits */} There is no limit to the number of concurrent Workflow Executions, albeit you must abide by the Workflow Execution's Event History limit. @@ -40,7 +40,7 @@ These limits are set with the following [dynamic configuration keys](https://git - `NumPendingSignalsLimit` - `NumPendingCancelRequestsLimit` -## Workflow Execution Callback limits {#workflow-execution-callback-limits} +## Workflow Execution Callback limits {/* #workflow-execution-callback-limits */} There is a limit to the total number of Workflow Callbacks that may be attached to a single Workflow Execution. Attaching [multiple Nexus callers to a handler Workflow](/nexus/operations#attaching-multiple-nexus-callers) may exceed these limits. @@ -49,7 +49,7 @@ These limits can be set with the following dynamic configuration keys: - [MaxCallbacksPerWorkflow](https://github.com/temporalio/temporal/blob/3b626075691c483871630d4a4df266e783f86328/common/dynamicconfig/constants.go#L998) - [MaxCHASMCallbacksPerWorkflow](https://github.com/temporalio/temporal/blob/3b626075691c483871630d4a4df266e783f86328/common/dynamicconfig/constants.go#L1005) -## Workflow Execution Nexus Operation Limits {#workflow-execution-nexus-operation-limits} +## Workflow Execution Nexus Operation Limits {/* #workflow-execution-nexus-operation-limits */} There is a limit to the maximum number of Nexus Operations in a Workflow before Continue-As-New is required. Each in-progress Nexus Operation generates a metadata entry in the Workflow Execution's mutable state. diff --git a/docs/encyclopedia/workflow/workflow-execution/timers-delays.mdx b/docs/encyclopedia/workflow/workflow-execution/timers-delays.mdx index 50f6941b20..66a6884aaf 100644 --- a/docs/encyclopedia/workflow/workflow-execution/timers-delays.mdx +++ b/docs/encyclopedia/workflow/workflow-execution/timers-delays.mdx @@ -15,7 +15,7 @@ tags: This page discusses [Timer](#timer) and [Start Delay](#delay-workflow-execution). -## What is a Timer? {#timer} +## What is a Timer? {/* #timer */} Temporal SDKs offer Timer APIs so that Workflow Executions are deterministic in their handling of time values. @@ -35,7 +35,7 @@ The duration of a Timer is fixed, and your Workflow might specify a value as sho We recommend that you consider the duration as a minimum time, one which will be rounded up slightly due to the latency involved with scheduling and firing the Timer. For example, setting a Timer for 11.97 seconds is guaranteed to delay execution for at least that long, but will likely be closer to 12 seconds in practice. -## What is a Start Delay? {#delay-workflow-execution} +## What is a Start Delay? {/* #delay-workflow-execution */} :::tip COMPATIBILITY diff --git a/docs/encyclopedia/workflow/workflow-execution/workflow-execution.mdx b/docs/encyclopedia/workflow/workflow-execution/workflow-execution.mdx index 03b37d05ed..349e0511de 100644 --- a/docs/encyclopedia/workflow/workflow-execution/workflow-execution.mdx +++ b/docs/encyclopedia/workflow/workflow-execution/workflow-execution.mdx @@ -26,7 +26,7 @@ This page provides an overview of Workflow Execution: - [Memo](#memo) - [State Transition](#state-transition) -## What is a Workflow Execution? {#workflow-execution} +## What is a Workflow Execution? {/* #workflow-execution */} While the Workflow Definition is the code that defines the Workflow, the Workflow Execution is created by executing that code. A Temporal Workflow Execution is a durable, reliable, and scalable function execution. @@ -64,7 +64,7 @@ Scalability is responsiveness in the presence of load. A single Workflow Execution is limited in size and throughput but is scalable because it can [Continue-As-New](/workflow-execution/continue-as-new) in response to load. A Temporal Application is scalable because the Temporal Platform is capable of supporting millions to billions of Workflow Executions executing concurrently, which is realized by the design and nature of the [Temporal Service](/temporal-service) and [Worker Processes](/workers#worker-process). -### Replays {#replay} +### Replays {/* #replay */} A Replay is the method by which a Workflow Execution resumes making progress. During a Replay the Commands that are generated are checked against an existing Event History. Replays are necessary and often happen to give the effect that Workflow Executions are resumable, reliable, and durable. @@ -78,7 +78,7 @@ If a failure occurs, the Workflow Execution picks up where the last recorded eve - [How to use Replay APIs using the TypeScript SDK](/develop/typescript/best-practices/testing-suite#replay) - [How to use Replay APIs using the .NET SDK](/develop/dotnet/best-practices/testing-suite#replay) -### Commands and awaitables {#commands-awaitables} +### Commands and awaitables {/* #commands-awaitables */} A Workflow Execution does two things: @@ -106,7 +106,7 @@ Awaitables are provided when using APIs for the following: - Spawning an [Activity Execution](/activity-execution): Progress can block on the result of the Activity Execution. - Starting a Timer: Progress can block until the Timer fires. -### What is a Command? {#command} +### What is a Command? {/* #command */} A Command is a requested action issued by a [Worker](/workers#worker) to the [Temporal Service](/temporal-service) after a [Workflow Task Execution](/tasks#workflow-task-execution) completes. @@ -123,7 +123,7 @@ There will always be [WorkflowTaskStarted](/references/events#workflowtaskstarte Commands are described in the [Command reference](/references/commands) and are defined in the [Temporal gRPC API](https://github.com/temporalio/api/blob/master/temporal/api/command/v1/message.proto). -### Status {#workflow-execution-status} +### Status {/* #workflow-execution-status */} A Workflow Execution can be either _Open_ or _Closed_. @@ -149,7 +149,7 @@ A _Closed_ status means that the Workflow Execution cannot make further progress - Terminated: The Workflow Execution was terminated. - Timed Out: The Workflow Execution reached a timeout limit. -### Workflow Execution Chain {#workflow-execution-chain} +### Workflow Execution Chain {/* #workflow-execution-chain */} A Workflow Execution Chain is a sequence of Workflow Executions that share the same Workflow Id. Each link in the Chain is often called a Workflow Run. @@ -164,7 +164,7 @@ A Workflow Execution is uniquely identified by its [Namespace](/namespaces), [Wo The [Workflow Execution Timeout](/encyclopedia/detecting-workflow-failures#workflow-execution-timeout) applies to a Workflow Execution Chain. The [Workflow Run Timeout](/encyclopedia/detecting-workflow-failures#workflow-run-timeout) applies to a single Workflow Execution (Workflow Run). -## What is a Memo? {#memo} +## What is a Memo? {/* #memo */} A Memo is a non-indexed set of Workflow Execution metadata that developers supply at start time or in Workflow code and that is returned when you describe or list Workflow Executions. @@ -182,7 +182,7 @@ Memos shouldn't store data that's critical to the execution of a Workflow, for s ::: -## What is a State Transition? {#state-transition} +## What is a State Transition? {/* #state-transition */} A State Transition is a unit of progress made by a [Workflow Execution](#workflow-execution). Each State Transition is recorded in a persistence store. diff --git a/docs/encyclopedia/workflow/workflow-execution/workflowid-runid.mdx b/docs/encyclopedia/workflow/workflow-execution/workflowid-runid.mdx index a574a6ec86..7183454792 100644 --- a/docs/encyclopedia/workflow/workflow-execution/workflowid-runid.mdx +++ b/docs/encyclopedia/workflow/workflow-execution/workflowid-runid.mdx @@ -27,7 +27,7 @@ In some cases, such as when running the same Workflow at recurring intervals usi In this case, all runs will have the same Workflow ID. However, each run will have a unique system-generated [Run ID](#run-id). -## What is a Run Id? {#run-id} +## What is a Run Id? {/* #run-id */} A Run Id is a globally unique, platform-level identifier for a [Workflow Execution](/workflow-execution). @@ -40,7 +40,7 @@ Each Workflow Execution within the chain is considered a _Run_. A Run Id uniquely identifies a Workflow Execution even if it shares a Workflow Id with other Workflow Executions. -### Which operations lead to non-determinism issues?{#run-id-non-determinism} +### Which operations lead to non-determinism issues? {/* #run-id-non-determinism */} An operation like `ContinueAsNew`, `Retry`, `Cron`, and `Reset` creates a [Workflow Execution Chain](/workflow-execution#workflow-execution-chain) as identified by the [`first_execution_run_id`](https://github.com/temporalio/api/blob/master/temporal/api/history/v1/message.proto). @@ -66,7 +66,7 @@ For more information, see the following link. - [`message.proto`](https://github.com/temporalio/api/blob/master/temporal/api/history/v1/message.proto#L75-L82) -## What is a Workflow Id? {#workflow-id} +## What is a Workflow Id? {/* #workflow-id */} A Workflow Id is a customizable, application-level identifier for a [Workflow Execution](/workflow-execution) that is unique to an Open Workflow Execution within a [Namespace](/namespaces). @@ -92,7 +92,7 @@ A [Workflow Id Conflict Policy](#workflow-id-conflict-policy) can be used to dec A Workflow Execution can be uniquely identified across all Namespaces by its [Namespace](/namespaces), Workflow Id, and [Run Id](#run-id). -### What is a Workflow Id Reuse Policy? {#workflow-id-reuse-policy} +### What is a Workflow Id Reuse Policy? {/* #workflow-id-reuse-policy */} A Workflow Id Reuse Policy determines whether a Workflow Execution is allowed to spawn with a particular Workflow Id, if that Workflow Id has been used with a previous, and now Closed, Workflow Execution. @@ -121,7 +121,7 @@ For Terminate if Running, the Retention Period is not a consideration for this p If there is an attempt to spawn a Workflow Execution with a Workflow Id Reuse Policy that won't allow it, the Server will prevent the Workflow Execution from spawning. -### What is a Workflow Id Conflict Policy? {#workflow-id-conflict-policy} +### What is a Workflow Id Conflict Policy? {/* #workflow-id-conflict-policy */} A Workflow Id Conflict Policy determines how to resolve a conflict when spawning a new Workflow Execution with a particular Workflow Id used by an existing Open Workflow Execution. See [Workflow Id Reuse Policy](#workflow-id-reuse-policy) for managing the reuse of a Workflow Id of a Closed Workflow. diff --git a/docs/evaluate/development-production-features/release-stages.mdx b/docs/evaluate/development-production-features/release-stages.mdx index 9cf7721ce9..da9f224d86 100644 --- a/docs/evaluate/development-production-features/release-stages.mdx +++ b/docs/evaluate/development-production-features/release-stages.mdx @@ -30,7 +30,7 @@ Product Release Guide Expectations: | **Feature Cloud pricing** | No additional cost. | Pricing changes are kept to a minimum. | Pricing is stable. | | **Feature Interoperability** | Limited. | Features are compatible with each other, unless otherwise stated. | Features are compatible with each other. | -## Pre-release {#pre-release} +## Pre-release {/* #pre-release */} **Access:** Most Pre-release features are released in the open source Temporal software and are publicly available. However, some features which are explicit to hosting Temporal Services, such as [API Keys](/cloud/api-keys), may be specific to Temporal Cloud. @@ -51,7 +51,7 @@ A Pre-release feature can be deprecated at any time. Pre-release features may be disabled by default, and can be enabled via configuration. Temporal Cloud customers can contact the Temporal account team or [Temporal Support Team](/cloud/support#support-ticket) to gain Pre-release access. -## Public Preview {#public-preview} +## Public Preview {/* #public-preview */} **Access:** New features in Public preview are available to everyone. @@ -65,7 +65,7 @@ This feedback will assist in guiding the improvements for General Availability. **Availability:** New Features in Public Preview may evolve. The APIs may undergo changes; however, Temporal's goal is to maintain backward compatibility. -## General Availability {#general-availability} +## General Availability {/* #general-availability */} **Access:** Features in General Availability are available to everyone. diff --git a/docs/evaluate/development-production-features/temporal-nexus.mdx b/docs/evaluate/development-production-features/temporal-nexus.mdx index b899950148..a46ad68378 100644 --- a/docs/evaluate/development-production-features/temporal-nexus.mdx +++ b/docs/evaluate/development-production-features/temporal-nexus.mdx @@ -86,7 +86,7 @@ Use the following decision tree to help determine if Nexus is right for your use -## Get started {#learn-more} +## Get started {/* #learn-more */} Join the [#nexus](https://temporalio.slack.com/archives/C07LQN0JK9B) channel in [Temporal Slack](https://t.mp/slack) to connect with the Nexus community. diff --git a/docs/evaluate/temporal-cloud/actions.mdx b/docs/evaluate/temporal-cloud/actions.mdx index 4c1da7700f..54ac308cf9 100644 --- a/docs/evaluate/temporal-cloud/actions.mdx +++ b/docs/evaluate/temporal-cloud/actions.mdx @@ -62,7 +62,7 @@ detailed _estimates_. For example, [History Event Types](https://docs.temporal.i for transparency, but do not always have a simple 1:1 relationship with Action Types. The Categories, Action types, and available endpoints are listed in the following sections: -## Workflow {#workflow} +## Workflow {/* #workflow */} - **Workflow started** - Occurs via client start, [Continue-As-New](/workflow-execution/continue-as-new), [Child Workflow](/child-workflows) @@ -104,7 +104,7 @@ available endpoints are listed in the following sections: | Reset Workflow | `reset_workflow` | `EVENT_TYPE_WORKFLOW_TASK_FAILED` Note: When `cause == WORKFLOW_TASK_FAILED_CAUSE_RESET_WORKFLOW` | | Record Workflow Heartbeat | `record_workflow_heartbeat` | N/A | -## Activity {#activity} +## Activity {/* #activity */} - **Activity started or retried**. Occurs each time an Activity is started or retried. - **Local Activity started**. All [Local Activities](/local-activity) associated with one Workflow Task count as a @@ -131,7 +131,7 @@ available endpoints are listed in the following sections: | Record Standalone Activity Heartbeat | `record_standalone_activity_heartbeat` | N/A | | Record Standalone Activity Heartbeat By ID | `record_standalone_activity_heartbeat_by_id` | N/A | -## Timer {#timer} +## Timer {/* #timer */} - **Timer started**. Includes implicit Timers that are started by a Temporal SDK when timeouts are set, such as `AwaitWithTimeout` in Go or `condition` in TypeScript. @@ -140,7 +140,7 @@ available endpoints are listed in the following sections: | ----------- | ------------- | -------------------------- | | Start Timer | `start_timer` | `EVENT_TYPE_TIMER_STARTED` | -## Signal {#signal} +## Signal {/* #signal */} - **Signal sent**. An Action occurs for every [Signal](https://docs.temporal.io/sending-messages#sending-signals), whether sent from a Client or from a Workflow. Also, one total action occurs for any @@ -153,7 +153,7 @@ available endpoints are listed in the following sections: | Signal External Workflow | `signal_external_workflow` | `EVENT_TYPE_SIGNAL_EXTERNAL_WORKFLOW_EXECUTION_INITIATED` (signaler event history) `EVENT_TYPE_WORKFLOW_EXECUTION_SIGNALED` (signaled Event history) Note: The UI shows a billable action only in the signaled Event history, not in the signaler Event history. | | Signal Workflow With Start | `signal_workflow_with_start` | `EVENT_TYPE_WORKFLOW_EXECUTION_STARTED` followed by `EVENT_TYPE_WORKFLOW_EXECUTION_SIGNALED` if the workflow didn’t exist, or only `EVENT_TYPE_WORKFLOW_EXECUTION_SIGNALED` if the Workflow existed. | -## Query {#query} +## Query {/* #query */} - **Query received by Worker**. An Action occurs for every [Query](https://docs.temporal.io/sending-messages#sending-queries), including viewing the call stack in the Temporal @@ -164,7 +164,7 @@ available endpoints are listed in the following sections: | -------------- | ---------------- | ------------------ | | Query Workflow | `query_workflow` | N/A | -## Update {#update} +## Update {/* #update */} - **Update received by Worker**. - Occurs for every successful [Update](https://docs.temporal.io/sending-messages#sending-updates) and every @@ -178,7 +178,7 @@ available endpoints are listed in the following sections: | Accept Workflow Update | `accept_workflow_update` | `EVENT_TYPE_WORKFLOW_EXECUTION_UPDATE_ACCEPTED` | | Reject Workflow Update | `reject_workflow_update` | `EVENT_TYPE_WORKFLOW_EXECUTION_UPDATE_REJECTED` Note: this event is never written to history. | -## Schedule {#schedule} +## Schedule {/* #schedule */} [Schedules](/schedule) allows you to schedule a Workflow to start at a particular time. Each execution of a Schedule accrues three actions: @@ -195,7 +195,7 @@ accrues three actions: | Delete Schedule | `delete_schedule` | N/A | | Schedule Workflow | `schedule_workflow` | `EVENT_TYPE_WORKFLOW_EXECUTION_STARTED` Note: `event.WorkflowExecutionStartedEventAttributes.indexedFields.TemporalScheduledById` tells if a Workflow was started by a Schedule. | -## Temporal Nexus {#nexus} +## Temporal Nexus {/* #nexus */} - For [Nexus Operation scheduled](/references/events#nexusoperationscheduled), the caller Workflow starting a Nexus Operation results in one Action on the caller Namespace. @@ -211,7 +211,7 @@ accrues three actions: | Schedule Nexus Operation | `schedule_nexus_operation` | `EVENT_TYPE_NEXUS_OPERATION_SCHEDULED` | | Request Nexus Operation Cancellation | `request_nexus_operation_cancellation` | `EVENT_TYPE_NEXUS_OPERATION_CANCEL_REQUESTED` | -## Export {#export} +## Export {/* #export */} [Workflow History Export](/cloud/export) enables you to export closed Workflow Histories to a cloud storage sink of your choice. @@ -223,7 +223,7 @@ choice. | ----------------------- | ----------- | ------------------ | | Export Workflow History | N/A | N/A | -## Fairness {#fairness} +## Fairness {/* #fairness */} For each hour a Namespace has the [Fairness](/develop/task-queue-priority-fairness#task-queue-fairness) feature enabled, an additional `0.1` Action is charged per Action in the Namespace. @@ -234,7 +234,7 @@ an additional `0.1` Action is charged per Action in the Namespace. | --------------- | ----------- | ------------------ | | Enable Fairness | N/A | N/A | -## Capacity {#capacity} +## Capacity {/* #capacity */} - For Namespace Capacity Temporal Resource Units (TRUs), Actions are generated up to the included hourly allocation for TRUs in any hour where TRUs are set and actual usage falls beneath the included hourly Action allocation. diff --git a/docs/evaluate/temporal-cloud/limits.mdx b/docs/evaluate/temporal-cloud/limits.mdx index a166d8f8dd..8fb6dbf525 100644 --- a/docs/evaluate/temporal-cloud/limits.mdx +++ b/docs/evaluate/temporal-cloud/limits.mdx @@ -121,7 +121,7 @@ This approach uniformly distributes the scheduled Workflow Execution launches th All read calls are subject to the Visibility API rate limit. -### Nexus Rate Limit {#nexus-rate-limits} +### Nexus Rate Limit {/* #nexus-rate-limits */} Nexus requests (such as starting a Nexus Operation or sending a Nexus completion callback) are counted as part of the overall Namespace RPS limit. If too many Nexus requests are sent at once, they may be throttled, along with other requests to the Namespace. @@ -268,7 +268,7 @@ This limit is non-configurable for Temporal Cloud. Read more about [Temporal Workflow Execution limits](/workflow-execution/limits) on the [Temporal Workflow](/workflows) documentation page. -### Per Workflow Callback limits {#per-workflow-callback-limits} +### Per Workflow Callback limits {/* #per-workflow-callback-limits */} A single Workflow Execution can have a maximum of 2000 total Callbacks. @@ -276,13 +276,13 @@ These limits may be exceeded when [multiple Nexus callers attach to the same han See the Nexus Encyclopedia entry for [additional details](/workflow-execution/limits#workflow-execution-callback-limits). -### Per Workflow Nexus Operation limits {#per-workflow-nexus-operation-limits} +### Per Workflow Nexus Operation limits {/* #per-workflow-nexus-operation-limits */} A single Workflow Execution can have a maximum of 30 in-flight Nexus Operations. See the Nexus Encyclopedia entry for [additional details](/workflow-execution/limits#workflow-execution-nexus-operation-limits). -### Nexus Operation request timeout {#nexus-operation-request-timeout} +### Nexus Operation request timeout {/* #nexus-operation-request-timeout */} Less than 10 seconds is the maximum duration for a Nexus handler to process a single Nexus start or cancel request. @@ -293,7 +293,7 @@ This includes fully processing a synchronous Nexus operation and starting an asy If a Nexus handler doesn’t process a start or cancel request within 10 seconds, it will receive a context deadline exceeded error, and the caller will retry, with an exponential backoff, for the ScheduleToClose duration for the overall Nexus Operation. This has a default and maximum as defined below in [Nexus Operation duration limits](/cloud/limits#nexus-operation-duration-limits). -### Nexus Operation duration limits {#nexus-operation-duration-limits} +### Nexus Operation duration limits {/* #nexus-operation-duration-limits */} Each Nexus Operation has a maximum ScheduleToClose duration of 60 days. This is most applicable to asynchronous Nexus Operations completed with an asynchronous callback using a separate Nexus request from the handler back to the caller Namespace. @@ -308,14 +308,14 @@ Timers have a maximum duration of 100 years in Temporal Cloud. ## Worker Versioning level -### Max Worker deployments limits {#max-worker-deployments-limits} +### Max Worker deployments limits {/* #max-worker-deployments-limits */} The maximum number of Worker deployments that the server allows to be registered in a single Namespace. Defaults to 100. -### Max versions in deployment limits {#max-versions-in-deployment-limits} +### Max versions in deployment limits {/* #max-versions-in-deployment-limits */} The maximum number of versions that the server allows to be registered in a single Worker deployments at a given time. Note that unused versions will be deleted by the system automatically when this limit is reached. Defaults to 100. -### Max Task Queues In Deployment Version limits {#max-task-queues-in-deployment-version-limits} +### Max Task Queues In Deployment Version limits {/* #max-task-queues-in-deployment-version-limits */} The maximum number of Task Queues that the server allows to be registered in a single Worker Deployment Version. Defaults to 100. diff --git a/docs/evaluate/temporal-cloud/pricing.mdx b/docs/evaluate/temporal-cloud/pricing.mdx index a7b02941a9..a7ec726786 100644 --- a/docs/evaluate/temporal-cloud/pricing.mdx +++ b/docs/evaluate/temporal-cloud/pricing.mdx @@ -35,12 +35,12 @@ For more exact estimates, please reach out to [our team](https://pages.temporal. Billing and cost information is available directly in the Temporal Cloud UI. For more information, visit the [Billing](/cloud/billing) page. -## Temporal Cloud pricing model {#pricing-model} +## Temporal Cloud pricing model {/* #pricing-model */} This section explains the basis of the Temporal Cloud pricing model and how it works. Your total invoice each calendar month is the combination of Temporal Cloud consumption ([Actions](#action) and [Storage](#storage)), and a [Temporal Cloud Plan](#base_plans) that includes [Support](/cloud/support#support). -### Temporal Cloud Plans {#base_plans} +### Temporal Cloud Plans {/* #base_plans */} **How plans work** @@ -71,7 +71,7 @@ Active and Retained Storage allocations are translated into GBh at a rate of 1GB ::: -### Actions {#action} +### Actions {/* #action */} **What are Temporal Actions?** @@ -81,7 +81,7 @@ They track billable operations within the Temporal Cloud Service, such as starti [Reach out](https://pages.temporal.io/contact-us) to our team for more information or to help size your number of Actions. -### Storage {#storage} +### Storage {/* #storage */} **How Workflow Storage works** @@ -98,7 +98,7 @@ Under this framework, a Workflow Execution has only two states, open (Active Sto Storage costs are measured in gigabyte-hours (GBh). -### Pricing options {#pricing-options} +### Pricing options {/* #pricing-options */} **How to Pay for Temporal Cloud** @@ -110,14 +110,14 @@ Both models meter and bill for three primary components: [Actions](#action), [St - With Commitments, you pre-purchase your Temporal Cloud spend with Temporal Credits. Temporal Credits pay for your Temporal Cloud consumption, including Temporal Cloud Plan charges. -## Pay-As-You-Go {#payg} +## Pay-As-You-Go {/* #payg */} **How does Pay-As-You-Go pricing work?** Pay-As-You-Go pricing is based on consumption. This section explains how you're billed each calendar month and gives examples. -### Action pricing {#payg-action-pricing} +### Action pricing {/* #payg-action-pricing */} Actions pricing starts at $50 per million Actions ($0.00005 per Action). You gain progressive volume discounts as you scale. @@ -145,7 +145,7 @@ Actions $250 (First Tier) + $225 (Second Tier) + $50 (Third Tier) = $525 ``` -### Storage pricing {#payg-storage-pricing} +### Storage pricing {/* #payg-storage-pricing */} Most accounts’ storage needs are met by our Temporal Cloud Plans. For additional storage within a calendar month, you are billed for Active and Retained Storage as follows: @@ -191,7 +191,7 @@ If you are signed up for Essentials, with $3,000 of monthly spend, your bill Greater of $100 or 5% ⨉ $3,000 = $150, so $150. ``` -## Commitment Pricing {#commitment-pricing} +## Commitment Pricing {/* #commitment-pricing */} **Commitments with Temporal Credits** @@ -256,11 +256,11 @@ Beginning credit balance of 72,000 - 5800 credits used = 66,200, Temporal Credit If you have additional questions about credits and volume-based pricing, please contact [sales](mailto:sales@temporal.io) or, if you're already a Temporal Cloud customer, reach out to your dedicated account executive. -## Other pricing {#other-pricing} +## Other pricing {/* #other-pricing */} Temporal Cloud has additional pricing for other elements of the platform. -### Capacity Modes {#capacity-modes-pricing} +### Capacity Modes {/* #capacity-modes-pricing */} **What are Capacity Modes?** @@ -307,7 +307,7 @@ To avoid being charged for provisioned capacity it is advised to "return" capaci -### High Availability feature pricing {#high-availability-features} +### High Availability feature pricing {/* #high-availability-features */} **How does the pricing for High Availability (HA) features work?** @@ -335,7 +335,7 @@ When upgrading an existing Namespace, some points to consider: - Temporal charges for all Actions of existing (ongoing) and new Workflows from the point of adding a replica. - Temporal charges for Replicated Storage of retained (historical), running (ongoing), and new Workflow Executions from the point of adding a new replica. -### Fairness pricing {#fairness-pricing} +### Fairness pricing {/* #fairness-pricing */} **How does pricing for Fairness work?** @@ -363,7 +363,7 @@ If each queue generates 5,000 Actions in a given hour (10,000 total), Fairness A |---------------|----------------------------|---------------------------------|-------------------------|-----------------|----------------------| | 2:00–3:00 PM | 5,000 | 5,000 | 10,000 | +1,000 | 11,000 | -### SCIM and SSO via SAML pricing {#sso-and-saml} +### SCIM and SSO via SAML pricing {/* #sso-and-saml */} **What costs are associated with SSO/SAML use?** @@ -374,7 +374,7 @@ Single sign-on (SSO) integration using SAML is included for all customers on the To enable SCIM (System for Cross-domain Identity Management), you need an Enterprise or Mission Critical plan or an add-on for the Business plan (+$500/month in addition to the Business plan). Please note that you must configure SSO via SAML to use SCIM. -### Use case cost estimates {#pricing-estimates} +### Use case cost estimates {/* #pricing-estimates */} Temporal Cloud uses a consumption-based pricing model based primarily on [Actions](#action) and [Storage](#storage). Each workload is different. @@ -392,7 +392,7 @@ Our team is always happy to [help you estimate costs](https://pages.temporal.io/ | Large | < $15K | Sustained throughput or multiple use cases | < 400M / month 
_(< 150 actions per second)_ | Data processing / sync
Retail order system
KYC & fraud detection | | Web Scale | $20K+ | "Web scale" and / or numerous use cases | 1B+ / month 
_(400+ actions per second)_ | Social media application
SaaS application service | -## Billing Questions FAQs {#pricing-faq} +## Billing Questions FAQs {/* #pricing-faq */} **What payment methods does Temporal accept?** diff --git a/docs/evaluate/temporal-cloud/security.mdx b/docs/evaluate/temporal-cloud/security.mdx index 0827a7fae9..44a8419d96 100644 --- a/docs/evaluate/temporal-cloud/security.mdx +++ b/docs/evaluate/temporal-cloud/security.mdx @@ -25,7 +25,7 @@ For information about the general security features of Temporal, see our [Platfo ::: -## Application and data {#applications-and-data} +## Application and data {/* #applications-and-data */} **What is the security model for applications and data in Temporal Cloud?** @@ -44,7 +44,7 @@ If you use this feature, data stored in Temporal Cloud remains encrypted even if By deploying a [Codec Server](/production-deployment/data-encryption) you can securely decrypt data in the [Temporal Web UI](/web-ui) without sharing encryption keys with Temporal. -## The platform {#the-platform} +## The platform {/* #the-platform */} **What is the security model for the Temporal Cloud platform?** diff --git a/docs/evaluate/temporal-cloud/service-availability.mdx b/docs/evaluate/temporal-cloud/service-availability.mdx index f29d59b70c..d7e9a75574 100644 --- a/docs/evaluate/temporal-cloud/service-availability.mdx +++ b/docs/evaluate/temporal-cloud/service-availability.mdx @@ -18,7 +18,7 @@ The operating envelope of Temporal Cloud includes throughput, latency, and limit Service regions are listed on [this page](/cloud/regions). If you need more details, [contact us](https://pages.temporal.io/contact-us). -## Throughput expectations {#throughput} +## Throughput expectations {/* #throughput */} **What kind of throughput can I get with Temporal Cloud?** @@ -28,7 +28,7 @@ With On-Demand Capacity, Namespace capacity is increased automatically along wit With Provisioned Capacity, you can control your capacity limits by requesting Temporal Resource Units (TRUs). -## Latency Service Level Objective (SLO) {#latency} +## Latency Service Level Objective (SLO) {/* #latency */} **What kind of latency can I expect from Temporal Cloud?** diff --git a/docs/evaluate/temporal-cloud/support.mdx b/docs/evaluate/temporal-cloud/support.mdx index ffb2874948..565a59246a 100644 --- a/docs/evaluate/temporal-cloud/support.mdx +++ b/docs/evaluate/temporal-cloud/support.mdx @@ -29,7 +29,7 @@ The content of this page applies to Temporal Cloud customers only. ::: -## Services offered by Temporal Cloud {#support} +## Services offered by Temporal Cloud {/* #support */} | | Essentials | Business | Enterprise | Mission Critical | | --------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | @@ -37,7 +37,7 @@ The content of this page applies to Temporal Cloud customers only. | Technical Guidance | Core platform config, platform access, documented features, and basic inquiries | Advanced technical support, Workflow troubleshooting, SDK implementations, and Worker configuration, Quarterly code review or design implementation best practices. | Business+ expert-led code reviews and design implementation best practices, available as needed | Enterprise+ expert guidance on Workflow latency monitoring and optimization; performance recommendations based on real time tests | | Billing & Cost Optimization | Generic Billing Questions | Generic Billing Questions | Quarterly review of spend | Quarterly review of spend, proactive cost optimization | -## Temporal Cloud support guarantees {#guarantees} +## Temporal Cloud support guarantees {/* #guarantees */} Temporal endeavors to ensure you are successful with Temporal Cloud. We offer explicit guarantees for support. @@ -79,7 +79,7 @@ P0: 24×7 (On Page Service) is offered for Enterprise and Mission Critical accou For pricing details of these support levels, please visit our [pricing page](/cloud/pricing). -## Temporal Dedicated Support Engineer {#dedicated-support-engineer} +## Temporal Dedicated Support Engineer {/* #dedicated-support-engineer */} Customers on the Mission Critical Plan and (by opting in) Enterprise customers receive access to a Dedicated Support Engineer. We offer: @@ -121,7 +121,7 @@ All Cloud customers pay for support as part of their plan. To request assistance from Temporal Support, see [Create a ticket](#support-ticket). -### Create a Ticket {#support-ticket} +### Create a Ticket {/* #support-ticket */} :::info @@ -138,7 +138,7 @@ To create a ticket in the Temporal Support Portal: 4. On the **Submit a ticket** page, enter the details of your request into the form. **Name**, **Subject**, and **Description** are required. 5. At the bottom of the form, choose **Submit**. -## Developer resources {#developer-resources} +## Developer resources {/* #developer-resources */} Temporal offers developer resources and a variety of hands-on tutorials to get you started and learn more advanced Temporal concepts. diff --git a/docs/glossary.md b/docs/glossary.md index e680202a9e..e13e98b3d7 100644 --- a/docs/glossary.md +++ b/docs/glossary.md @@ -649,7 +649,7 @@ A Temporal Application is a set of Workflow Executions. -#### [Temporal CLI](/cli) {#cli} +#### [Temporal CLI](/cli) {/* #cli */} The Temporal CLI is the most recent version of Temporal's command-line tool. diff --git a/docs/production-deployment/data-encryption.mdx b/docs/production-deployment/data-encryption.mdx index abfb860a60..08c3437994 100644 --- a/docs/production-deployment/data-encryption.mdx +++ b/docs/production-deployment/data-encryption.mdx @@ -45,7 +45,7 @@ For encryption implementation examples, see the following samples: - [TypeScript](https://github.com/temporalio/samples-typescript/tree/main/encryption) - [.NET](https://github.com/temporalio/samples-dotnet/tree/main/src/Encryption) -## Codec Server setup {#codec-server-setup} +## Codec Server setup {/* #codec-server-setup */} Use a Codec Server to programmatically decode your encoded [payloads](/dataconversion#payload). diff --git a/docs/production-deployment/self-hosted-guide/archival.mdx b/docs/production-deployment/self-hosted-guide/archival.mdx index 05bd5fa91a..85a18a0812 100644 --- a/docs/production-deployment/self-hosted-guide/archival.mdx +++ b/docs/production-deployment/self-hosted-guide/archival.mdx @@ -43,7 +43,7 @@ manually and when deploying through [helm charts](https://github.com/temporalio/helm-charts/blob/main/charts/temporal/templates/server-configmap.yaml). It can be enabled in the server [configuration](https://github.com/temporalio/temporal/blob/main/config/development.yaml). -### Set up Archival {#set-up-archival} +### Set up Archival {/* #set-up-archival */} To set up [Archival](/temporal-service/archival), decide the following: @@ -58,7 +58,7 @@ Take the following steps to set up Archival: 2. [Configure Archival options](#configure-archival-options). 3. [Create an Archiving Namespace](#create-an-archiving-namespace). -#### Choose an Archival provider {#choose-an-archival-provider} +#### Choose an Archival provider {/* #choose-an-archival-provider */} Temporal directly supports several providers: @@ -77,7 +77,7 @@ Temporal directly supports several providers: Save the provider URI so you can pass it when you create a Namespace with Archival enabled. -#### Configure Archival options {#configure-archival-options} +#### Configure Archival options {/* #configure-archival-options */} Configure Archival in [`config/development.yaml`](https://github.com/temporalio/temporal/blob/main/config/development.yaml#L93): @@ -139,7 +139,7 @@ The following table shows the available configuration options and their accepted Additional resources: [Temporal Service configuration reference](/references/configuration). -#### Create an Archiving Namespace {#create-an-archiving-namespace} +#### Create an Archiving Namespace {/* #create-an-archiving-namespace */} Although Archival is configured at the Temporal Service level, it operates independently within each Namespace. If you don't specify an Archival URI during Namespace creation, the Namespace uses `namespaceDefaults.archival.history.URI` @@ -151,7 +151,7 @@ Archival is supported in [Global Namespaces](/global-namespace) (Namespaces that is running in a Global Namespace, it first runs on the active cluster; later it runs on the standby cluster. Before archiving, a history check is done to see what has been previously archived. -#### Test your Archival setup {#test-your-archival-setup} +#### Test your Archival setup {/* #test-your-archival-setup */} To test Archival locally, start by running a Temporal server: @@ -182,7 +182,7 @@ Next, run a sample Workflow such as the When the Workflow Execution closes, Temporal schedules archival processing. -#### Retrieve archived history {#retrieve-archived-history} +#### Retrieve archived history {/* #retrieve-archived-history */} You can retrieve archived Event Histories by copying the `workflowId` and `runId` of the completed Workflow from the log output and running the following command: @@ -193,7 +193,7 @@ output and running the following command: ./temporal workflow show --workflow-id="my-workflow-id" --run-id="my-run-id" --namespace="my-namespace" ``` -### Create a custom Archiver {#custom-archiver} +### Create a custom Archiver {/* #custom-archiver */} To archive data with a given provider, using the [Archival](/temporal-service/archival) feature, Temporal must have a corresponding Archiver component installed. The platform does not limit you to the existing providers. To use a provider diff --git a/docs/production-deployment/self-hosted-guide/checklist.mdx b/docs/production-deployment/self-hosted-guide/checklist.mdx index 8a8280534d..0daec095e1 100644 --- a/docs/production-deployment/self-hosted-guide/checklist.mdx +++ b/docs/production-deployment/self-hosted-guide/checklist.mdx @@ -43,7 +43,7 @@ Significant engineering and ongoing effort is required to resolve several potent Each of these components is an essential part of building a mission critical Temporal Service. Without demonstrated architectural durability, the value of Temporal's [Durable Execution](https://temporal.io/how-it-works) model is compromised. -## Scalability with Variable or Growing Workloads {#scaling-and-metrics} +## Scalability with Variable or Growing Workloads {/* #scaling-and-metrics */} Workloads can be highly variable, and you may experience sustained workload spikes. Temporal recommends scaling your clusters to well above the average throughput. diff --git a/docs/production-deployment/self-hosted-guide/monitoring.mdx b/docs/production-deployment/self-hosted-guide/monitoring.mdx index 5ba6f672f3..03d88064ef 100644 --- a/docs/production-deployment/self-hosted-guide/monitoring.mdx +++ b/docs/production-deployment/self-hosted-guide/monitoring.mdx @@ -182,7 +182,7 @@ For more details on configuring Grafana dashboards, see the [Grafana Dashboards From here, you can configure Grafana [Alerts](https://grafana.com/docs/grafana/latest/alerting/) for any monitored parameters, add custom metrics to your Temporal SDK code, and use these observability features to help scale your Temporal deployment. Refer to the [Cluster metrics](/references/cluster-metrics) and [SDK metrics](/references/sdk-metrics) reference for more. -## Configuring Temporal Service health checks {#health-checks} +## Configuring Temporal Service health checks {/* #health-checks */} The [Frontend Service](/temporal-service/temporal-server#frontend-service) supports TCP or [gRPC](https://github.com/grpc/grpc/blob/875066b61e3b57af4bb1d6e36aabe95a4f6ba4f7/src/proto/grpc/health/v1/health.proto#L45) health checks on port 7233. @@ -214,7 +214,7 @@ service { If you are installing and running Temporal via [Helm chart](https://github.com/temporalio/helm-charts), you can also [provide additional parameters](https://github.com/temporalio/helm-charts?tab=readme-ov-file#exploring-metrics-via-grafana) to populate and explore a Grafana dashboard out of the box. -## Datadog {#datadog} +## Datadog {/* #datadog */} Datadog has a Temporal integration for collecting Temporal Service metrics. Once you've [configured Prometheus](#prometheus), you can configure the [Datadog Agent](https://docs.datadoghq.com/integrations/temporal/). diff --git a/docs/production-deployment/self-hosted-guide/multi-cluster-replication.mdx b/docs/production-deployment/self-hosted-guide/multi-cluster-replication.mdx index 38d3d64172..047283d55f 100644 --- a/docs/production-deployment/self-hosted-guide/multi-cluster-replication.mdx +++ b/docs/production-deployment/self-hosted-guide/multi-cluster-replication.mdx @@ -411,7 +411,7 @@ T = 2: task A is loaded. At this time, due to the rebuild of a Workflow Execution's mutable state (conflict resolution), Task A is no longer relevant (Task A's corresponding Event belongs to non-current branch). Task processing logic will verify both the Event Id and version of the Task against a corresponding Workflow Execution's mutable state, then discard task A. -## How to set up Multi-Cluster Replication {#set-up-multi-cluster-replication} +## How to set up Multi-Cluster Replication {/* #set-up-multi-cluster-replication */} The [Multi-Cluster Replication](/self-hosted-guide/multi-cluster-replication) feature asynchronously replicates Workflow Execution Event Histories from active Clusters to other passive Clusters, and can be enabled by setting the appropriate values in the `clusterMetadata` section of your configuration file. diff --git a/docs/production-deployment/self-hosted-guide/security.mdx b/docs/production-deployment/self-hosted-guide/security.mdx index 47f7f572a3..3a13685c5b 100644 --- a/docs/production-deployment/self-hosted-guide/security.mdx +++ b/docs/production-deployment/self-hosted-guide/security.mdx @@ -146,11 +146,11 @@ temporal-ui: For more general guidance for configuration, refer to the [Temporal UI README](https://github.com/temporalio/ui?tab=readme-ov-file#configuration). For more details on configuration with Docker, refer to [Temporal UI Config](https://github.com/temporalio/ui/blob/c95265ee6431fd0f6cf78ae06373885d66a8ee0c/server/docker/config-template.yaml). -## Temporal Service plugins {#plugins} +## Temporal Service plugins {/* #plugins */} The Temporal Service supports some pluggable components. -### What is a ClaimMapper Plugin? {#claim-mapper} +### What is a ClaimMapper Plugin? {/* #claim-mapper */} The Claim Mapper component is a pluggable component that extracts Claims from JSON Web Tokens (JWTs). @@ -261,7 +261,7 @@ Multiple permissions for the same Namespace are overridden by the `ClaimMapper`. } ``` -### What is an Authorizer Plugin? {#authorizer-plugin} +### What is an Authorizer Plugin? {/* #authorizer-plugin */} The `Authorizer` plugin contains a single `Authorize` method, which is invoked for each incoming API call. `Authorize` receives information about the API call, along with the role and permission claims of the caller. @@ -304,7 +304,7 @@ temporalServer, err := temporal.NewServer( ) ``` -#### How to authorize SDK API calls {#authorize-api-calls} +#### How to authorize SDK API calls {/* #authorize-api-calls */} When authentication is enabled, you can authorize API calls made to the Frontend Service. @@ -339,7 +339,7 @@ Related read: - [How to secure a Temporal Service](/security) -## Data Converter {#data-converter} +## Data Converter {/* #data-converter */} Each Temporal SDK provides a [Data Converter](/dataconversion) that can be customized with a custom [Payload Codec](/payload-codec) to encode and secure your data. diff --git a/docs/production-deployment/self-hosted-guide/upgrade-server.mdx b/docs/production-deployment/self-hosted-guide/upgrade-server.mdx index 0419e841df..b9f702f0f5 100644 --- a/docs/production-deployment/self-hosted-guide/upgrade-server.mdx +++ b/docs/production-deployment/self-hosted-guide/upgrade-server.mdx @@ -14,7 +14,7 @@ tags: - Self-hosting --- -## How to upgrade the Temporal Server version {#upgrade-server} +## How to upgrade the Temporal Server version {/* #upgrade-server */} If a newer version of the [Temporal Server](/temporal-service/temporal-server) is available, a notification appears in the Temporal Web UI. diff --git a/docs/production-deployment/self-hosted-guide/visibility.mdx b/docs/production-deployment/self-hosted-guide/visibility.mdx index 1748b1042c..882a28fb6a 100644 --- a/docs/production-deployment/self-hosted-guide/visibility.mdx +++ b/docs/production-deployment/self-hosted-guide/visibility.mdx @@ -39,7 +39,7 @@ Supported Visibility stores include: - PostgreSQL v12 and later with Temporal Server v1.20 and later - SQLite v3.31.0 and later with Temporal Server v1.20 and later -## Current and legacy Visibility support {#supported-databases} +## Current and legacy Visibility support {/* #supported-databases */} [Advanced Visibility](/visibility#advanced-visibility) is the current generation of Temporal Visibility. It supports the modern query model, including [custom Search Attributes](/search-attribute#custom-search-attribute). @@ -66,7 +66,7 @@ You can use any combination of the supported databases for your Persistence and Temporal Server v1.21 introduced support for a secondary Visibility store in your Temporal Service to enable [Dual Visibility](/dual-visibility). This is useful for migrating your Visibility store database. -## How to set up MySQL Visibility store {#mysql} +## How to set up MySQL Visibility store {/* #mysql */} :::tip Support, stability, and dependency info @@ -166,7 +166,7 @@ Note that the script uses [temporal-sql-tool](https://github.com/temporalio/temporal/blob/3b982585bf0124839e697952df4bba01fe4d9543/tools/sql/main.go) to run the setup. -## How to set up PostgreSQL Visibility store {#postgresql} +## How to set up PostgreSQL Visibility store {/* #postgresql */} :::tip Support, stability, and dependency info @@ -261,7 +261,7 @@ Note that the script uses [temporal-sql-tool](https://github.com/temporalio/temporal/blob/3b982585bf0124839e697952df4bba01fe4d9543/tools/sql/main.go) to run the setup. -## How to set up SQLite Visibility store {#sqlite} +## How to set up SQLite Visibility store {/* #sqlite */} :::tip Support, stability, and dependency info @@ -332,12 +332,12 @@ https://github.com/temporalio/temporal/blob/main/schema/sqlite/v3/visibility/sch For an example of setting up the SQLite schema, see [Temporalite](https://github.com/temporalio/temporalite/blob/main/server.go) setup. -## Legacy standard Visibility configuration {#legacy-standard-visibility} +## Legacy standard Visibility configuration {/* #legacy-standard-visibility */} The following section applies to older self-hosted deployments that still use standard Visibility. For new deployments, use one of the advanced Visibility backends described earlier on this page. -### How to set up Cassandra Visibility store {#cassandra} +### How to set up Cassandra Visibility store {/* #cassandra */} :::tip Support, stability, and dependency info @@ -421,7 +421,7 @@ setup_cassandra_schema() { } ``` -## How to integrate Elasticsearch or OpenSearch into a Temporal Service {#elasticsearch} +## How to integrate Elasticsearch or OpenSearch into a Temporal Service {/* #elasticsearch */} You can integrate Elasticsearch or OpenSearch with your Temporal Service as your Visibility store. We recommend using one of these backends for large-scale operations on the Temporal Service. @@ -550,7 +550,7 @@ Ensure that the following privileges are granted for the Elasticsearch Temporal - [cluster privileges](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-privileges.html#privileges-list-cluster): `monitor` or `manage`. -## How to set up Dual Visibility {#dual-visibility} +## How to set up Dual Visibility {/* #dual-visibility */} To enable [Dual Visibility](/dual-visibility), set up a secondary Visibility store with your primary Visibility store, and configure your Temporal Service to enable read and/or write operations on the secondary Visibility store. @@ -743,7 +743,7 @@ For details on the configuration options, see: - [Secondary Visibility dynamic configuration reference](/references/dynamic-configuration#secondary-visibility-settings) - [Migrating Visibility databases](#migrating-visibility-database) -## How to migrate Visibility database {#migrating-visibility-database} +## How to migrate Visibility database {/* #migrating-visibility-database */} To migrate your Visibility database, [set up a secondary Visibility store](#dual-visibility) to enable [Dual Visibility](/dual-visibility), and update the dynamic configuration in your Temporal Service to update the read @@ -866,7 +866,7 @@ When you are ready to deprecate your primary store, follow these steps. closeIdleConnectionsInterval: 15s ``` -## Managing custom Search Attributes {#custom-search-attributes} +## Managing custom Search Attributes {/* #custom-search-attributes */} To manage custom Search Attributes on Temporal Cloud, use the [`tcld`](/cloud/tcld/namespace#search-attributes) CLI tool. With Temporal Cloud, you can create and rename custom Search Attributes. If you need to delete a custom Search Attribute, contact Support at [support.temporal.io](https://support.temporal.io). @@ -886,7 +886,7 @@ Using sensitive data in either names or values risks exposure to anyone with Nam ::: -### How to create custom Search Attributes {#create-custom-search-attributes} +### How to create custom Search Attributes {/* #create-custom-search-attributes */} Creating a custom Search Attribute in your Visibility store makes it available to use in your Workflow metadata and [List Filters](/list-filter). @@ -964,7 +964,7 @@ add_custom_search_attributes() { When your Visibility store is set up and running, these custom Search Attributes are available to use in your Workflow code. -### How to remove custom Search Attributes {#remove-custom-search-attributes} +### How to remove custom Search Attributes {/* #remove-custom-search-attributes */} To remove a Search Attribute key from your self-hosted Temporal Service Visibility store, use the command `temporal operator search-attribute remove`. Removing Search Attributes is not supported on Temporal Cloud. diff --git a/docs/production-deployment/worker-deployments/serverless-workers/aws-lambda.mdx b/docs/production-deployment/worker-deployments/serverless-workers/aws-lambda.mdx index a5db1f32fb..000efbe447 100644 --- a/docs/production-deployment/worker-deployments/serverless-workers/aws-lambda.mdx +++ b/docs/production-deployment/worker-deployments/serverless-workers/aws-lambda.mdx @@ -33,7 +33,7 @@ APIs are experimental and may be subject to backwards-incompatible changes. ::: -## Prerequisites {#prerequisites} +## Prerequisites {/* #prerequisites */} - A Temporal Cloud account with an AWS-hosted Namespace, or a self-hosted Temporal Service v1.31.0 or later. The Namespace's cloud provider must match the serverless compute provider. @@ -58,7 +58,7 @@ APIs are experimental and may be subject to backwards-incompatible changes. ::: -## 1. Write Worker code {#write-worker-code} +## 1. Write Worker code {/* #write-worker-code */} Write a Worker that runs inside a Lambda function. The Worker handles the per-invocation lifecycle: connecting to Temporal, polling for tasks, and gracefully shutting down before the invocation deadline. @@ -180,11 +180,11 @@ For details on configuration options, Lambda-tuned defaults, and observability, -## 2. Deploy Lambda function {#deploy-lambda-function} +## 2. Deploy Lambda function {/* #deploy-lambda-function */} Build your Worker for the Lambda runtime, package it as a zip, and deploy it to AWS Lambda. -### i. Build and package {#build-and-package} +### i. Build and package {/* #build-and-package */} @@ -241,7 +241,7 @@ zip -r function.zip lib/ node_modules/ workflow-bundle.js -### ii. Deploy Lambda function {#deploy-lambda-function-step} +### ii. Deploy Lambda function {/* #deploy-lambda-function-step */} Replace the placeholder values and run the following command to create the Lambda function in your AWS environment. @@ -350,7 +350,7 @@ Version. ::: -## 3. Configure IAM for Temporal invocation (Cloud only) {#configure-iam} +## 3. Configure IAM for Temporal invocation (Cloud only) {/* #configure-iam */} This section applies to Temporal Cloud. For self-hosted Temporal Service deployments, see [Self-hosted setup](/production-deployment/worker-deployments/serverless-workers/self-hosted-setup#create-invocation-role) @@ -496,7 +496,7 @@ aws cloudformation describe-stacks --stack-name --query 'Stacks[0]. Use this role ARN in your Worker Deployment Version's compute configuration. -## 4. Create Worker Deployment Version {#create-worker-deployment-version} +## 4. Create Worker Deployment Version {/* #create-worker-deployment-version */} Create a [Worker Deployment Version](/production-deployment/worker-deployments/worker-versioning) with a compute provider that points to your Lambda function. The compute configuration tells Temporal how to invoke your Worker: the @@ -565,7 +565,7 @@ To verify that Temporal can reach your Lambda function, go to **Workers** > **De open the **Actions** menu on the version and click **Validate Connection**. This checks that Temporal can assume the IAM role and invoke the function. -## 5. Set version as current {#set-current-version} +## 5. Set version as current {/* #set-current-version */} If you created the version through the Temporal UI, the version is already current and you can skip this step. @@ -578,7 +578,7 @@ temporal worker deployment set-current-version \ --build-id build-1 ``` -## 6. Verify deployment {#verify-deployment} +## 6. Verify deployment {/* #verify-deployment */} Start a Workflow on the same Task Queue to confirm that Temporal invokes your Lambda Worker. diff --git a/docs/production-deployment/worker-deployments/serverless-workers/self-hosted-setup.mdx b/docs/production-deployment/worker-deployments/serverless-workers/self-hosted-setup.mdx index f0bba471b3..0f5a4e7464 100644 --- a/docs/production-deployment/worker-deployments/serverless-workers/self-hosted-setup.mdx +++ b/docs/production-deployment/worker-deployments/serverless-workers/self-hosted-setup.mdx @@ -40,14 +40,14 @@ Once setup is complete, follow the [AWS Lambda deployment guide](/production-deployment/worker-deployments/serverless-workers/aws-lambda) to deploy your Worker. -## Ensure Lambda can reach the Temporal Service {#ensure-network-reachability} +## Ensure Lambda can reach the Temporal Service {/* #ensure-network-reachability */} The [Temporal Service frontend](/temporal-service/temporal-server#frontend-service) must be reachable from the Lambda execution environment. How to achieve this depends on your network setup. If the Temporal Service runs on a private network, you may need [VPC access for Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html), VPC peering, or a similar mechanism to allow the Lambda function to connect to the Temporal frontend. -## Enable the Worker Controller Instance {#enable-worker-controller} +## Enable the Worker Controller Instance {/* #enable-worker-controller */} [WCI](/serverless-workers#how-invocation-works) is the server component that monitors Task Queues and invokes compute providers. It is disabled by default and must be enabled through @@ -80,7 +80,7 @@ workercontroller.enabled: The Temporal Service watches the dynamic config file for changes and applies updates without a restart. -## Configure AWS credentials {#configure-aws-credentials} +## Configure AWS credentials {/* #configure-aws-credentials */} The Temporal Service needs AWS credentials to assume an IAM role that invokes Lambda functions. How you provide credentials depends on where the Temporal Service runs. @@ -101,7 +101,7 @@ AWS_REGION= These credentials must belong to an IAM user or role that has `sts:AssumeRole` permission for the Lambda invocation role. -## Create the Lambda invocation role {#create-invocation-role} +## Create the Lambda invocation role {/* #create-invocation-role */} Temporal invokes Lambda functions by assuming an IAM role in your AWS account. This role needs `lambda:GetFunction` and `lambda:InvokeFunction` permission on your Worker Lambda functions, and a trust policy that allows the Temporal server's @@ -224,7 +224,7 @@ aws cloudformation describe-stacks \ Use this role ARN when creating the Worker Deployment Version. -## Next steps {#next-steps} +## Next steps {/* #next-steps */} Follow the [AWS Lambda deployment guide](/production-deployment/worker-deployments/serverless-workers/aws-lambda) to write your Worker code, deploy it to Lambda, and create a Worker Deployment Version with the IAM role from the previous diff --git a/docs/production-deployment/worker-deployments/worker-versioning.mdx b/docs/production-deployment/worker-deployments/worker-versioning.mdx index 64fb2817ae..d0c4323da7 100644 --- a/docs/production-deployment/worker-deployments/worker-versioning.mdx +++ b/docs/production-deployment/worker-deployments/worker-versioning.mdx @@ -78,7 +78,7 @@ Self-hosted users: ::: -## Getting Started with Worker Versioning {#definition} +## Getting Started with Worker Versioning {/* #definition */} To get started with Worker Versioning, you should understand some concepts around versioning and deployments. @@ -109,7 +109,7 @@ To get started with Worker Versioning, you should understand some concepts aroun - For a given Workflow, its [**Target Worker Deployment Version**](/worker-versioning#versioning-definitions) is the version it will move to next. -## Setting up your deployment system {#deployment-systems} +## Setting up your deployment system {/* #deployment-systems */} If you haven't already, you'll want to pick a container deployment solution for your Workers. @@ -252,11 +252,11 @@ worker = Temporalio::Worker.new( -## Choosing a Versioning Behavior {#choosing-behavior} +## Choosing a Versioning Behavior {/* #choosing-behavior */} The right versioning behavior depends on how long your Workflows run relative to your deployment frequency. -### Decision guide {#decision-guide} +### Decision guide {/* #decision-guide */} | Workflow Duration | Uses Continue-as-New? | Recommended Behavior | Patching Required? | | ---------------------------------------- | --------------------- | -------------------------------------------------------- | ------------------ | @@ -265,7 +265,7 @@ The right versioning behavior depends on how long your Workflows run relative to | **Long** (weeks to years) | Yes | `PINNED` + [upgrade on CaN](#upgrade-on-continue-as-new) | Never | | **Long** (weeks to years) | No | `AUTO_UPGRADE` + patching | Yes | -### Examples by Workflow type {#behavior-examples} +### Examples by Workflow type {/* #behavior-examples */} | Workflow Type | Duration | Recommended Behavior | Notes | | -------------------- | ------------ | -------------------------- | ----------------------------------- | @@ -527,7 +527,7 @@ When you change the behavior to Auto-Upgrade, the Workflow will resume work on t ::: -## Upgrading on Continue-as-New {#upgrade-on-continue-as-new} +## Upgrading on Continue-as-New {/* #upgrade-on-continue-as-new */} Long-running Workflows that use [Continue-as-New](/workflow-execution/continue-as-new) can upgrade to newer Worker Deployment Versions at Continue-as-New boundaries without requiring patching. @@ -544,7 +544,7 @@ This feature is in Public Preview as an experimental SDK-level option. ::: -### How it works {#upgrade-on-can-how-it-works} +### How it works {/* #upgrade-on-can-how-it-works */} By default, Pinned Workflows stay on their original Worker Deployment Version even when they Continue-as-New. With the upgrade option enabled: @@ -553,7 +553,7 @@ upgrade option enabled: 2. The Temporal Server tells the workflow when a new [Target Version](/worker-versioning#versioning-definitions) becomes available 3. When the Workflow performs Continue-as-New with the upgrade option, the new run starts on the [Target Version](/worker-versioning#versioning-definitions) -### Checking for new versions {#checking-for-new-versions} +### Checking for new versions {/* #checking-for-new-versions */} When a new Worker Deployment Version becomes Current or Ramping, active Workflows can detect this through `target_worker_deployment_version_changed`: @@ -604,7 +604,7 @@ func (w *Workflows) ContinueAsNewWithVersionUpgradeV2( } ``` -### Limitations {#upgrade-on-can-limitations} +### Limitations {/* #upgrade-on-can-limitations */} :::caution Current Limitations diff --git a/docs/references/errors.mdx b/docs/references/errors.mdx index 25ee29a6a5..8702ecd7f9 100644 --- a/docs/references/errors.mdx +++ b/docs/references/errors.mdx @@ -18,7 +18,7 @@ This reference lists possible [Workflow Task](/tasks#workflow-task) errors and h Each of the below errors corresponds with a [WorkflowTaskFailedCause](https://api-docs.temporal.io/#temporal.api.enums.v1.WorkflowTaskFailedCause), which appears in [Events](/workflow-execution/event#event) under `workflow_task_failed_event_attributes`. -## Bad Cancel Timer Attributes {#bad-cancel-timer-attributes} +## Bad Cancel Timer Attributes {/* #bad-cancel-timer-attributes */} This error indicates that the [Workflow Task](/tasks#workflow-task) failed while attempting to cancel a Timer. @@ -27,20 +27,20 @@ This error indicates that the [Workflow Task](/tasks#workflow-task) failed while Check your Timer attributes for a missing Timer Id value. Add a valid Timer Id and redeploy the code. -## Bad Cancel Workflow Execution Attributes {#bad-cancel-workflow-execution-attributes} +## Bad Cancel Workflow Execution Attributes {/* #bad-cancel-workflow-execution-attributes */} The [Workflow Task](/tasks#workflow-task) failed due to unset [CancelWorkflowExecution](/references/commands#cancelworkflowexecution) attributes. Reset any missing attributes and redeploy the Workflow Task. -## Bad Complete Workflow Execution Attributes {#bad-complete-workflow-execution-attributes} +## Bad Complete Workflow Execution Attributes {/* #bad-complete-workflow-execution-attributes */} This error indicates that the [Workflow Task](/tasks#workflow-task) failed due to unset attributes on [CompleteWorkflowExecution](/references/commands#completeworkflowexecution). Reset any missing attributes. Adjust the size of your Payload if it exceeds size limits. -## Bad Continue as New Attributes {#bad-continue-as-new-attributes} +## Bad Continue as New Attributes {/* #bad-continue-as-new-attributes */} This error indicates that the [Workflow Task](/tasks#workflow-task) failed to validate a [ContinueAsNew](/references/commands#continueasnewworkflowexecution) attribute. The attribute could be unset or invalid. @@ -50,14 +50,14 @@ If the payload or memo exceeded size limits, adjust the input size. Check that the [Workflow](/workflows) is validating search attributes after unaliasing keys. -## Bad Fail Workflow Execution Attributes {#bad-fail-workflow-execution-attributes} +## Bad Fail Workflow Execution Attributes {/* #bad-fail-workflow-execution-attributes */} This error indicates that the [Workflow Task](/tasks#workflow-task) failed due to unset [FailWorkflowExecution](/references/commands#failworkflowexecution) attributes. If you encounter this error, make sure that `StartToCloseTimeout` or `ScheduleToCloseTimeout` are set. Restart the [Worker](/workers) that the [Workflow](/workflows) and [Activity](/activities) are registered to. -## Bad Modify Workflow Properties Attributes {#bad-modify-workflow-properties-attributes} +## Bad Modify Workflow Properties Attributes {/* #bad-modify-workflow-properties-attributes */} This error indicates that the [Workflow Task](/tasks#workflow-task) failed to validate attributes on a property in the Upsert Memo or in a payload. These attributes are either unset or exceeding size limits. @@ -65,13 +65,13 @@ These attributes are either unset or exceeding size limits. Reset any unset and empty attributes. Adjust the size of the [Memo](/workflow-execution#memo) or payload to fit within the system's limits. -## Bad Record Marker Attributes {#bad-record-marker-attributes} +## Bad Record Marker Attributes {/* #bad-record-marker-attributes */} This error indicates that the [Workflow Task](/tasks#workflow-task) failed due to an unset or incorrect [Marker](/references/events#markerrecorded) name. Enter a valid Marker name and redeploy the Task. -## Bad Request Cancel Activity Attributes {#bad-request-cancel-activity-attributes} +## Bad Request Cancel Activity Attributes {/* #bad-request-cancel-activity-attributes */} This error either indicates the possibility of unset attributes for [RequestCancelActivity](/references/commands#requestcancelactivitytask), or an invalid History Builder state. @@ -80,7 +80,7 @@ Reset any unset attributes before retrying the [Workflow Task](/tasks#workflow-t If you continue to see this error, review your code for [nondeterministic causes](/workflow-definition#non-deterministic-change). -## Bad Request Cancel External Workflow Execution Attributes {#bad-request-cancel-external-workflow-execution} +## Bad Request Cancel External Workflow Execution Attributes {/* #bad-request-cancel-external-workflow-execution */} This error indicates that the [Workflow Task](/tasks#workflow-task) failed while trying to cancel an external Workflow. Unset or invalid attributes can cause this to occur. @@ -91,7 +91,7 @@ Adjust any fields that exceed length limits. If [Child Workflow](/child-workflows) is set to `Start` and `RequestCancel`, remove one of these attributes. A Child Workflow cannot perform both actions in the same Workflow Task. -## Bad Schedule Activity Attributes {#bad-schedule-activity-attributes} +## Bad Schedule Activity Attributes {/* #bad-schedule-activity-attributes */} This error indicates unset or invalid attributes for [`ScheduleActivityTask`](/references/commands#scheduleactivitytask) or [`CompleteWorkflowExecution`](/references/commands#completeworkflowexecution). @@ -104,7 +104,7 @@ This error indicates unset or invalid attributes for ScheduleNexusOperation, for Inspect the reason given in the error for mitigation when possible. -## Bad Search Attributes {#bad-search-attributes} +## Bad Search Attributes {/* #bad-search-attributes */} This error indicates that the [Workflow Task](/tasks#workflow-task) has unset or invalid [Search Attributes](/search-attribute). This can cause Workflow Tasks to continue to retry without success. @@ -112,20 +112,20 @@ This can cause Workflow Tasks to continue to retry without success. Make sure that all attributes are defined before retrying the Task. Adjust the size of the Payload to fit within the system's size limits. -## Bad Signal Input Size {#bad-signal-input-size} +## Bad Signal Input Size {/* #bad-signal-input-size */} This error indicates that the Payload has exceeded the [Signal's](/sending-messages#sending-signals) available input size. Adjust the size of the Payload, and redeploy the [Workflow Task](/tasks#workflow-task). -## Bad Signal Workflow Execution Attributes {#bad-signal-workflow-execution-attributes} +## Bad Signal Workflow Execution Attributes {/* #bad-signal-workflow-execution-attributes */} This error indicates that the [Workflow Task](/tasks#workflow-task) failed to validate attributes for [SignalExternalWorkflowExecution](/references/commands#signalexternalworkflowexecution). Reset any unset, missing, nil, or invalid attributes. Adjust the input to fit within the system's size limits. -## Bad Start Child Execution Attributes {#bad-start-child-execution-attributes} +## Bad Start Child Execution Attributes {/* #bad-start-child-execution-attributes */} This error indicates that the [Workflow Task](/tasks#workflow-task) failed to validate attributes for [`StartChildWorkflowExecution`](/references/commands#startchildworkflowexecution) @@ -133,7 +133,7 @@ Adjust the input size of the attributes to fall within the system's size limits. Make sure that [Search Attribute](/search-attribute) validation is performed after unaliasing keys. -## Bad Start Timer Attributes {#bad-start-timer-attributes} +## Bad Start Timer Attributes {/* #bad-start-timer-attributes */} This error indicates that the scheduled [Event](/workflow-execution/event#event) is missing a Timer Id. @@ -141,13 +141,13 @@ This error indicates that the scheduled [Event](/workflow-execution/event#event) Set a valid Timer Id and retry the [Workflow Task](/tasks#workflow-task). -## Cause Bad Binary {#cause-bad-binary} +## Cause Bad Binary {/* #cause-bad-binary */} This error indicates that the [Worker](/workers) deployment returned a bad binary checksum. {/* TODO: get more information about binary */} -## Cause Bad Update {#cause-bad-update} +## Cause Bad Update {/* #cause-bad-update */} {/* TODO: add link to Workflow Update page when written */} @@ -158,13 +158,13 @@ This error indicates that a [Workflow Execution](/workflow-execution) tried to c This error might indicate usage of an unsupported SDK. Make sure you're using a [supported SDK](/encyclopedia/temporal-sdks). -## Cause Reset Workflow {#cause-reset-workflow} +## Cause Reset Workflow {/* #cause-reset-workflow */} This error indicates that the [Workflow Task](/tasks#workflow-task) failed due to a request to reset the [Workflow](/workflows). If the system hasn't started a new Workflow, manually reset the Workflow. -## Cause Unhandled Update {#cause-unhandled-update} +## Cause Unhandled Update {/* #cause-unhandled-update */} `UnhandledUpdate` occurs when a Workflow Update is received by the Temporal Server while a Workflow Task being processed on a Worker produces a Command that would cause the Workflow to transition to a closed state. @@ -172,27 +172,27 @@ Temporal rejects the Workflow Task completion to guarantee that the Update is ev This error can happen when the Workflow receives frequent Updates. -## Cause Unspecified {#cause-unspecified} +## Cause Unspecified {/* #cause-unspecified */} This error indicates that the [Workflow Task](/tasks#workflow-task) has failed for an unknown reason. If you see this error, examine your Workflow Definition. -## Failover Close Command {#failover-close-command} +## Failover Close Command {/* #failover-close-command */} This error indicates that a [Namespace](/namespaces) failover forced the [Workflow Task](/tasks#workflow-task) to close. The system automatically schedules a retry when this error occurs. {/* TODO: troubleshooting */} -## Force Close Command {#force-close-command} +## Force Close Command {/* #force-close-command */} This error indicates that the [Workflow Task](/tasks#workflow-task) was forced to close. A retry will be scheduled if the error is recoverable. {/* TODO: more info */} -## gRPC Message Too Large {#grpc-message-too-large} +## gRPC Message Too Large {/* #grpc-message-too-large */} This error occurs when the Workflow Task response exceeds the gRPC message size limit of 4 MB. The Workflow Execution is automatically terminated because this is a non-recoverable error. @@ -204,27 +204,27 @@ Break work into smaller batches, reduce the size of Workflow returns, use Contin See the [BlobSizeLimitError troubleshooting guide](/troubleshooting/blob-size-limit-error) for detailed resolution strategies. -## Nondeterminism Error {#non-deterministic-error} +## Nondeterminism Error {/* #non-deterministic-error */} The [Workflow Task](/tasks#workflow-task) failed due to a [nondeterminism error](/workflow-definition#non-deterministic-change). {/* TODO: info */} -## Pending Activities Limit Exceeded {#pending-activities-limit-exceeded} +## Pending Activities Limit Exceeded {/* #pending-activities-limit-exceeded */} The [Workflow](/workflows) has reached capacity for pending [Activities](/activities). Therefore, the [Workflow Task](/tasks#workflow-task) was failed to prevent the creation of another Activity. Let the Workflow complete any current Activities before redeploying the code. -## Pending Child Workflows Limit Exceeded {#pending-child-workflows-limit-exceeded} +## Pending Child Workflows Limit Exceeded {/* #pending-child-workflows-limit-exceeded */} This error indicates that the [Workflow](/workflows) has reached capacity for pending [Child Workflows](/child-workflows). Therefore, the [Workflow Task](/tasks#workflow-task) was failed to prevent additional Child Workflows from being added. Wait for the system to finish any currently running Child Workflows before redeploying this Task. -## Pending Nexus Operations Limit Exceeded {#pending-nexus-operations-limit-exceeded} +## Pending Nexus Operations Limit Exceeded {/* #pending-nexus-operations-limit-exceeded */} The Workflow has reached capacity for pending Nexus Operations. Therefore, the Workflow Task was failed to prevent the creation of another Nexus Operation. @@ -232,28 +232,28 @@ Let the Workflow complete any current Nexus Operation before retrying the Task. See [Per Workflow Nexus Operation Limits](/cloud/limits#per-workflow-nexus-operation-limits) for details. -## Pending Request Cancel Limit Exceeded {#pending-request-cancel-limit-exceeded} +## Pending Request Cancel Limit Exceeded {/* #pending-request-cancel-limit-exceeded */} This error indicates that the [Workflow Task](/tasks#workflow-task) failed after attempting to add more cancel requests. The [Workflow](/workflows) has reached capacity for pending requests to cancel other Workflows, and cannot accept more requests. If you see this error, give the system time to process pending requests before retrying the Task. -## Pending Signals Limit Exceeded {#pending-signals-limit-exceeded} +## Pending Signals Limit Exceeded {/* #pending-signals-limit-exceeded */} The Workflow has reached capacity for pending Signals. Therefore, the [Workflow Task](/tasks#workflow-task) was failed after attempting to add more [Signals](/sending-messages#sending-signals) to an external Workflow. Wait for Signals to be processed by the Workflow before retrying the Task. -## Reset Sticky Task Queue {#reset-sticky-task-queue} +## Reset Sticky Task Queue {/* #reset-sticky-task-queue */} This error indicates that the Sticky [Task Queue](/task-queue) needs to be reset. If you see this error, reset the Sticky Task Queue. The system will retry automatically. -## Resource Exhausted Cause Concurrent Limit {#resource-exhausted-cause-concurrent-limit} +## Resource Exhausted Cause Concurrent Limit {/* #resource-exhausted-cause-concurrent-limit */} This error indicates that the concurrent [poller count](/develop/worker-performance#poller-count) has been exhausted. @@ -261,38 +261,38 @@ This error indicates that the concurrent [poller count](/develop/worker-performa Adjust the poller count per [Worker](/workers). -## Resource Exhausted Cause Persistence Limit {#resource-exhausted-cause-persistence-limit} +## Resource Exhausted Cause Persistence Limit {/* #resource-exhausted-cause-persistence-limit */} This error indicates that the persistence rate limit has been reached. {/* TODO: more info needed */} -## Resource Exhausted Cause RPS Limit {#resource-exhausted-cause-rps-limit} +## Resource Exhausted Cause RPS Limit {/* #resource-exhausted-cause-rps-limit */} This error indicates that the [Workflow](/workflows) has exhausted its RPS limit. {/* TODO: more info needed */} -## Resource Exhausted Cause System Overload {#resource-exhausted-cause-system-overload} +## Resource Exhausted Cause System Overload {/* #resource-exhausted-cause-system-overload */} This error indicates that the system is overloaded and cannot allocate further resources to [Workflow Tasks](/tasks#workflow-task). {/* TODO: more info needed */} -## Resource Exhausted Cause Unspecified {#resource-exhausted-cause-unspecified} +## Resource Exhausted Cause Unspecified {/* #resource-exhausted-cause-unspecified */} This error indicates that an unknown cause is preventing resources from being allocated to further [Workflow Tasks](/tasks#workflow-task). {/* TODO: more info needed */} -## Schedule Activity Duplicate Id {#schedule-activity-duplicate-id} +## Schedule Activity Duplicate Id {/* #schedule-activity-duplicate-id */} The [Workflow Task](/tasks#workflow-task) failed because the [Activity](/activities) Id is already in use. Check your code to see if you've already specified the same Activity Id in your [Workflow](/workflows). Enter another Activity Id, and try running the Workflow Task again. -## Start Timer Duplicate Id {#start-timer-duplicate-id} +## Start Timer Duplicate Id {/* #start-timer-duplicate-id */} This error indicates that a Timer with the given Timer Id has already started. @@ -300,7 +300,7 @@ This error indicates that a Timer with the given Timer Id has already started. Try entering a different Timer Id, and retry the [Workflow Task](/tasks#workflow-task). -## Unhandled Command {#unhandled-command} +## Unhandled Command {/* #unhandled-command */} This error indicates new available [Events](/references/events) since the last [Workflow Task](/tasks#workflow-task) started. The Workflow Task was failed because the [Workflow](/workflows) attempted to close itself without handling the new Events. @@ -313,7 +313,7 @@ To prevent this error, drain the Signal Channel with the ReceiveAsync function. If you continue to see this error, check your logs for failing Workflow Tasks. The Workflow may have been picked up by a different [Worker](/workers#worker). -## Workflow Worker Unhandled Failure {#workflow-worker-unhandled-failure} +## Workflow Worker Unhandled Failure {/* #workflow-worker-unhandled-failure */} This error indicates that the [Workflow Task](/tasks#workflow-task) encountered an unhandled failure from the [Workflow Definition](/workflow-definition). diff --git a/docs/references/failures.mdx b/docs/references/failures.mdx index 718a387ae8..1cd2c51ee1 100644 --- a/docs/references/failures.mdx +++ b/docs/references/failures.mdx @@ -170,7 +170,7 @@ When a Nexus Operation handler throws an Application Failure, it is retried by d Nexus Operation handlers can avoid retrying by setting an Application Failure's `non_retryable` flag to true. When a non-retryable error is returned from a Nexus handler, the overall Nexus Operation Execution is failed and the error is returned to the caller’s Workflow Execution as a Nexus Operation Failure. -### Setting the Next Retry Delay {#activity-next-retry-delay} +### Setting the Next Retry Delay {/* #activity-next-retry-delay */} By setting the Next Retry Delay for a given Application Failure, you can tell the server to wait that amount of time before trying the Activity or Workflow again. This will override whatever the Retry Policy would have computed for your specific exception. @@ -179,7 +179,7 @@ Java: [NextRetryDelay](/develop/java/activities/timeouts#activity-next-retry-del TypeScript: [nextRetryDelay](/develop/typescript/activities/timeouts#activity-next-retry-delay) PHP: [NextRetryDelay](/develop/php/activities/timeouts#activity-next-retry-delay) -### Nexus errors {#nexus-errors} +### Nexus errors {/* #nexus-errors */} #### Default mapping diff --git a/docs/tctl-v1/index.mdx b/docs/tctl-v1/index.mdx index 3b6815776f..8684f95983 100644 --- a/docs/tctl-v1/index.mdx +++ b/docs/tctl-v1/index.mdx @@ -45,7 +45,7 @@ Workflow, show Event History, and Signal Workflow). - [tctl taskqueue](/tctl-v1/taskqueue/) - [tctl workflow](/tctl-v1/workflow/) -## How to install tctl {#install} +## How to install tctl {/* #install */} > The Temporal tctl documentation covers version 1.17 of the Temporal CLI. diff --git a/docs/troubleshooting/blob-size-limit-error.mdx b/docs/troubleshooting/blob-size-limit-error.mdx index 55e1f75d2a..0bb8120b7d 100644 --- a/docs/troubleshooting/blob-size-limit-error.mdx +++ b/docs/troubleshooting/blob-size-limit-error.mdx @@ -39,7 +39,7 @@ include: - `CompleteWorkflowExecutionCommandAttributes.Result exceeds size limit` - `WORKFLOW_TASK_FAILED_CAUSE_BAD_UPDATE_WORKFLOW_EXECUTION_MESSAGE` -### Error behavior {#payload-error-behavior} +### Error behavior {/* #payload-error-behavior */} The behavior when a payload exceeds the size limit depends on the SDK version. @@ -99,7 +99,7 @@ The error message depends on which operation carried the oversized gRPC message - `WORKFLOW_TASK_FAILED_CAUSE_GRPC_MESSAGE_TOO_LARGE` - `ScheduleToCloseTimeout` (Activities only, see [error behavior](#grpc-error-behavior) below) -### Error behavior {#grpc-error-behavior} +### Error behavior {/* #grpc-error-behavior */} The behavior when a gRPC message exceeds the size limit depends on the SDK version. diff --git a/docs/troubleshooting/serverless-workers.mdx b/docs/troubleshooting/serverless-workers.mdx index 4d5f5e571c..a64b2134d4 100644 --- a/docs/troubleshooting/serverless-workers.mdx +++ b/docs/troubleshooting/serverless-workers.mdx @@ -46,7 +46,7 @@ When a Serverless Worker invocation works correctly, the following sequence happ Start by determining whether the Lambda function is being invoked at all, then narrow down from there. -## Is the Lambda function being invoked? {#is-lambda-invoked} +## Is the Lambda function being invoked? {/* #is-lambda-invoked */} Check the Lambda function's CloudWatch metrics or invocation logs. @@ -59,11 +59,11 @@ If there are no invocations, continue to [Lambda is not being invoked](#lambda-n If the Lambda is being invoked but Workflows are not progressing, skip to [Lambda is invoked but Tasks are not completing](#lambda-invoked-not-completing). -## Lambda is not being invoked {#lambda-not-invoked} +## Lambda is not being invoked {/* #lambda-not-invoked */} Work through the following checks in order. -### Validate the connection to Lambda {#validate-connection} +### Validate the connection to Lambda {/* #validate-connection */} Start by verifying that Temporal can reach the Lambda function. Go to **Workers > Deployments > select your deployment**, open the **Actions** menu on the version, and click **Validate Connection**. A successful validation @@ -83,7 +83,7 @@ registers the Worker Deployment Version and binds the Task Queue on the server, To fix the issue, create or update the Worker Deployment Version with the compute provider flags as described in the [deploy guide](/production-deployment/worker-deployments/serverless-workers/aws-lambda#create-worker-deployment-version). -### Check that the version is set as current {#check-version-current} +### Check that the version is set as current {/* #check-version-current */} The Worker Deployment Version must be set as the current version for new Tasks to route to it. If you created the version through the CLI, you need to @@ -91,7 +91,7 @@ version through the CLI, you need to You can verify the current version with `temporal worker deployment describe`. -### Check that the WCI is detecting Tasks {#check-wci-detecting-tasks} +### Check that the WCI is detecting Tasks {/* #check-wci-detecting-tasks */} If the connection validates successfully but the Lambda is still not being invoked, the [Worker Controller Instance (WCI)](/serverless-workers#worker-controller-instance) may not be detecting Tasks on the @@ -120,12 +120,12 @@ the execution result and any errors directly, making it easier to identify confi CloudWatch logs. Once the Lambda runs successfully and the Worker connects to Temporal, the Task Queue binding is established. -## Lambda is invoked but Tasks are not completing {#lambda-invoked-not-completing} +## Lambda is invoked but Tasks are not completing {/* #lambda-invoked-not-completing */} If CloudWatch shows Lambda invocations but Workflows are not progressing, the problem is in the Worker's execution within the Lambda function. -### Check Lambda execution logs {#check-execution-logs} +### Check Lambda execution logs {/* #check-execution-logs */} Check CloudWatch logs for errors during Worker startup. In the AWS Console, go to **CloudWatch > Log groups > /aws/lambda/your-function-name** and look for recent error messages. @@ -139,7 +139,7 @@ Common errors include: - **TLS errors**: The TLS certificate or key is missing, expired, or does not match the Namespace. - **Authentication errors**: The API key is invalid or does not have access to the Namespace. -### Check for Lambda timeout {#check-lambda-timeout} +### Check for Lambda timeout {/* #check-lambda-timeout */} If the Lambda function reaches its configured timeout before the Worker finishes processing, AWS terminates the invocation. @@ -151,7 +151,7 @@ For long-running Activities, increase the Lambda timeout and the Worker's shutdo [Tuning for long-running Activities](/serverless-workers#tuning-for-long-running-activities) for guidance on how these values relate. -### Check that the deployment name and build ID match {#check-deployment-match} +### Check that the deployment name and build ID match {/* #check-deployment-match */} If CloudWatch shows rapid, repeated invocations with no Workflow progress, the deployment name or build ID in the Worker code may not match the Worker Deployment Version configuration. diff --git a/docs/web-ui.mdx b/docs/web-ui.mdx index 11f2a72491..c5f425da27 100644 --- a/docs/web-ui.mdx +++ b/docs/web-ui.mdx @@ -53,7 +53,7 @@ For start time and end time, users can set their preferred date and time format Select a Workflow Execution to view the Workflow Execution's History, Workers, Relationships, pending Activities and Nexus Operations, Queries, and Metadata. -### Saved Views {#saved-views} +### Saved Views {/* #saved-views */} Saved Views let you save and reuse your frequently used visibility queries in the Temporal Web UI. Instead of recreating complex filters every time, you can save them once and apply them with a single click. @@ -136,7 +136,7 @@ Saved Views that use relative times will be shared with absolute time. ::: -## Task Failures View {#task-failures-view} +## Task Failures View {/* #task-failures-view */} The Task Failures view is a pre-defined Saved View that displays Workflows that have a Workflow Task failure. These Workflows are still running, but one of their Tasks has failed or timed out. @@ -148,7 +148,7 @@ You can also cancel the Workflow by clicking the Request Cancellation button on Our system monitors Workflow task execution patterns in real-time. When a Workflow experiences five consecutive task failures or timeouts, it gets automatically flagged. The moment the Workflow recovers with a successful task, the flag clears. This smart threshold filters out minor glitches while surfacing Workflows with genuine problems. -### Activating Task Failures View {#activate-task-failures-view} +### Activating Task Failures View {/* #activate-task-failures-view */} This is enabled by default for Temporal Cloud users. If you're self-hosting Temporal, you'll need to update the `system.numConsecutiveWorkflowTaskProblemsToTriggerSearchAttribute` [dynamic config](/references/dynamic-configuration). diff --git a/docusaurus.config.js b/docusaurus.config.js index 4dfefcd3ac..6ae4ab2134 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -454,9 +454,16 @@ module.exports = async function createConfigAsync() { }, ], ], + markdown: { + mdx1Compat: { + // Required for snipsync HTML comment markers (, ) + comments: true, + admonitions: true, + }, + }, future: { v4: true, - experimental_faster: true, + faster: true, }, }; diff --git a/package.json b/package.json index b9667af1ca..048e1ff8e5 100644 --- a/package.json +++ b/package.json @@ -49,14 +49,14 @@ ] }, "dependencies": { - "@docusaurus/core": "^3.8.1", - "@docusaurus/faster": "^3.8.1", + "@docusaurus/core": "^3.10.1", + "@docusaurus/faster": "^3.10.1", "@docusaurus/mdx-loader": "^3.10.1", "@docusaurus/module-type-aliases": "^3.10.1", - "@docusaurus/plugin-content-docs": "^3.8.1", - "@docusaurus/preset-classic": "^3.8.1", - "@docusaurus/theme-common": "^3.8.1", - "@docusaurus/types": "^3.8.1", + "@docusaurus/plugin-content-docs": "^3.10.1", + "@docusaurus/preset-classic": "^3.10.1", + "@docusaurus/theme-common": "^3.10.1", + "@docusaurus/types": "^3.10.1", "@mdx-js/react": "^3.0.0", "@types/react": "^19.1.0", "@types/react-dom": "^19.1.0", diff --git a/yarn.lock b/yarn.lock index 66feb8d39f..17c90220ef 100644 --- a/yarn.lock +++ b/yarn.lock @@ -30,6 +30,14 @@ "@algolia/autocomplete-plugin-algolia-insights" "1.19.2" "@algolia/autocomplete-shared" "1.19.2" +"@algolia/autocomplete-core@^1.19.2": + version "1.19.8" + resolved "https://registry.yarnpkg.com/@algolia/autocomplete-core/-/autocomplete-core-1.19.8.tgz#7c84c771d28643fb00d09026c05013fb97aeea23" + integrity sha512-3YEorYg44niXcm7gkft3nXYItHd44e8tmh4D33CTszPgP0QWkaLEaFywiNyJBo7UL/mqObA/G9RYuU7R8tN1IA== + dependencies: + "@algolia/autocomplete-plugin-algolia-insights" "1.19.8" + "@algolia/autocomplete-shared" "1.19.8" + "@algolia/autocomplete-plugin-algolia-insights@1.19.2": version "1.19.2" resolved "https://registry.yarnpkg.com/@algolia/autocomplete-plugin-algolia-insights/-/autocomplete-plugin-algolia-insights-1.19.2.tgz#3584b625b9317e333d1ae43664d02358e175c52d" @@ -37,11 +45,23 @@ dependencies: "@algolia/autocomplete-shared" "1.19.2" +"@algolia/autocomplete-plugin-algolia-insights@1.19.8": + version "1.19.8" + resolved "https://registry.yarnpkg.com/@algolia/autocomplete-plugin-algolia-insights/-/autocomplete-plugin-algolia-insights-1.19.8.tgz#f60d21edbe2a42e6d4e2215430733e3f51641471" + integrity sha512-ZvJWO8ZZJDpc1LNM2TTBdmQsZBLMR4rU5iNR2OYvEeFBiaf/0ESnRSSLQbryarJY4SVxtoz6A2ZtDMNM+iQEAA== + dependencies: + "@algolia/autocomplete-shared" "1.19.8" + "@algolia/autocomplete-shared@1.19.2": version "1.19.2" resolved "https://registry.yarnpkg.com/@algolia/autocomplete-shared/-/autocomplete-shared-1.19.2.tgz#c0b7b8dc30a5c65b70501640e62b009535e4578f" integrity sha512-jEazxZTVD2nLrC+wYlVHQgpBoBB5KPStrJxLzsIFl6Kqd1AlG9sIAGl39V5tECLpIQzB3Qa2T6ZPJ1ChkwMK/w== +"@algolia/autocomplete-shared@1.19.8": + version "1.19.8" + resolved "https://registry.yarnpkg.com/@algolia/autocomplete-shared/-/autocomplete-shared-1.19.8.tgz#5d723d8bdb448efbb1b0e1c7ff94cc18e5b1dc0e" + integrity sha512-h5hf2t8ejF6vlOgvLaZzQbWs5SyH2z4PAWygNAvvD/2RI29hdQ54ldUGwqVuj9Srs+n8XUKTPUqb7fvhBhQrnQ== + "@algolia/client-abtesting@5.49.0": version "5.49.0" resolved "https://registry.npmjs.org/@algolia/client-abtesting/-/client-abtesting-5.49.0.tgz" @@ -1199,13 +1219,6 @@ "@babel/plugin-transform-modules-commonjs" "^7.27.1" "@babel/plugin-transform-typescript" "^7.28.5" -"@babel/runtime-corejs3@^7.25.9": - version "7.29.2" - resolved "https://registry.yarnpkg.com/@babel/runtime-corejs3/-/runtime-corejs3-7.29.2.tgz#cb86ad06e7a1d39224afb12a874301085e071846" - integrity sha512-Lc94FOD5+0aXhdb0Tdg3RUtqT6yWbI/BbFWvlaSJ3gAb9Ks+99nHRDKADVqC37er4eCB0fHyWT+y+K3QOvJKbw== - dependencies: - core-js-pure "^3.48.0" - "@babel/runtime@^7.1.2", "@babel/runtime@^7.10.3", "@babel/runtime@^7.12.13", "@babel/runtime@^7.12.5", "@babel/runtime@^7.21.0", "@babel/runtime@^7.25.9", "@babel/runtime@^7.27.6", "@babel/runtime@^7.3.4": version "7.28.6" resolved "https://registry.npmjs.org/@babel/runtime/-/runtime-7.28.6.tgz" @@ -1645,29 +1658,29 @@ resolved "https://registry.npmjs.org/@discoveryjs/json-ext/-/json-ext-0.5.7.tgz" integrity sha512-dBVuXR082gk3jsFp7Rd/JI4kytwGHecnCoTtXFb7DB6CNHp4rg5k1bhg0nWdLGLnOV71lmDzGQaLMy8iPLY0pw== -"@docsearch/core@4.6.2": - version "4.6.2" - resolved "https://registry.yarnpkg.com/@docsearch/core/-/core-4.6.2.tgz#0a6fdc13b1eb12153cb19316f911479b67f7bd58" - integrity sha512-/S0e6Dj7Zcm8m9Rru49YEX49dhU11be68c+S/BCyN8zQsTTgkKzXlhRbVL5mV6lOLC2+ZRRryaTdcm070Ug2oA== +"@docsearch/core@4.6.3": + version "4.6.3" + resolved "https://registry.yarnpkg.com/@docsearch/core/-/core-4.6.3.tgz#9954c75c3ae28418e06f8e7537a920d6cd2bc22e" + integrity sha512-rUOujwIpxJRgD7+kicVsI3D5sqBvdiRTquzWBpTEXZs8ZXfGbfzpus5HqumaNYTppN2HvH8E2yNuRwYdHJeOlA== -"@docsearch/css@4.6.2": - version "4.6.2" - resolved "https://registry.yarnpkg.com/@docsearch/css/-/css-4.6.2.tgz#986776619dccbf798176c75e858cc22f5e710bb4" - integrity sha512-fH/cn8BjEEdM2nJdjNMHIvOVYupG6AIDtFVDgIZrNzdCSj4KXr9kd+hsehqsNGYjpUjObeKYKvgy/IwCb1jZYQ== +"@docsearch/css@4.6.3": + version "4.6.3" + resolved "https://registry.yarnpkg.com/@docsearch/css/-/css-4.6.3.tgz#a94065af4a996dd927dc5dda383395e583dbd638" + integrity sha512-nlOwcXcsNAptQl4vlL4MA78qNJKO0Qlds5GuBjCoePgkebTXLSf8Qt1oyZ3YBshYupKXG9VRGEsk1zr23d+bzQ== -"@docsearch/react@^3.9.0 || ^4.1.0": - version "4.6.2" - resolved "https://registry.yarnpkg.com/@docsearch/react/-/react-4.6.2.tgz#e6c65fb87fb943eefaa936debe6d31bb51b25056" - integrity sha512-/BbtGFtqVOGwZx0dw/UfhN/0/DmMQYnulY4iv0tPRhC2JCXv0ka/+izwt3Jzo1ZxXS/2eMvv9zHsBJOK1I9f/w== +"@docsearch/react@^3.9.0 || ^4.3.2": + version "4.6.3" + resolved "https://registry.yarnpkg.com/@docsearch/react/-/react-4.6.3.tgz#80df785f9c5e484c960b914a22ea2a3e4c7210ad" + integrity sha512-Bg2wdDsoQVlNCcEKuEJAU04tvHCqgx8rIu+uIoM4pRtcx3TBKJuXutJik3LTA8LRc9YEyHkrYUrmcC0D7BYf+g== dependencies: "@algolia/autocomplete-core" "1.19.2" - "@docsearch/core" "4.6.2" - "@docsearch/css" "4.6.2" + "@docsearch/core" "4.6.3" + "@docsearch/css" "4.6.3" -"@docusaurus/babel@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/babel/-/babel-3.9.2.tgz#f956c638baeccf2040e482c71a742bc7e35fdb22" - integrity sha512-GEANdi/SgER+L7Japs25YiGil/AUDnFFHaCGPBbundxoWtCkA2lmy7/tFmgED4y1htAy6Oi4wkJEQdGssnw9MA== +"@docusaurus/babel@3.10.1": + version "3.10.1" + resolved "https://registry.yarnpkg.com/@docusaurus/babel/-/babel-3.10.1.tgz#2f714f682117658ba43d308e9b35b6a73a105227" + integrity sha512-DZzFO1K3v/GoEt1fx1DiYHF4en+PuhtQf1AkQJa5zu3CoeKSpr5cpQRUlz3jr0m44wyzmSXu9bVpfir+N4+8bg== dependencies: "@babel/core" "^7.25.9" "@babel/generator" "^7.25.9" @@ -1677,25 +1690,24 @@ "@babel/preset-react" "^7.25.9" "@babel/preset-typescript" "^7.25.9" "@babel/runtime" "^7.25.9" - "@babel/runtime-corejs3" "^7.25.9" "@babel/traverse" "^7.25.9" - "@docusaurus/logger" "3.9.2" - "@docusaurus/utils" "3.9.2" + "@docusaurus/logger" "3.10.1" + "@docusaurus/utils" "3.10.1" babel-plugin-dynamic-import-node "^2.3.3" fs-extra "^11.1.1" tslib "^2.6.0" -"@docusaurus/bundler@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/bundler/-/bundler-3.9.2.tgz#0ca82cda4acf13a493e3f66061aea351e9d356cf" - integrity sha512-ZOVi6GYgTcsZcUzjblpzk3wH1Fya2VNpd5jtHoCCFcJlMQ1EYXZetfAnRHLcyiFeBABaI1ltTYbOBtH/gahGVA== +"@docusaurus/bundler@3.10.1": + version "3.10.1" + resolved "https://registry.yarnpkg.com/@docusaurus/bundler/-/bundler-3.10.1.tgz#82fa5079f3787a67502e25f82d37d05ec5de0cc3" + integrity sha512-HIqQPvbqnnQRe4NsBd1774KRarjXqS6wHsWELtyuSs1gCfvixJO2jUGH/OEBtr1Gvzpw+ze5CjGMvSJ8UE1KUw== dependencies: "@babel/core" "^7.25.9" - "@docusaurus/babel" "3.9.2" - "@docusaurus/cssnano-preset" "3.9.2" - "@docusaurus/logger" "3.9.2" - "@docusaurus/types" "3.9.2" - "@docusaurus/utils" "3.9.2" + "@docusaurus/babel" "3.10.1" + "@docusaurus/cssnano-preset" "3.10.1" + "@docusaurus/logger" "3.10.1" + "@docusaurus/types" "3.10.1" + "@docusaurus/utils" "3.10.1" babel-loader "^9.2.1" clean-css "^5.3.3" copy-webpack-plugin "^11.0.0" @@ -1713,20 +1725,20 @@ tslib "^2.6.0" url-loader "^4.1.1" webpack "^5.95.0" - webpackbar "^6.0.1" - -"@docusaurus/core@3.9.2", "@docusaurus/core@^3.8.1": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/core/-/core-3.9.2.tgz#cc970f29b85a8926d63c84f8cffdcda43ed266ff" - integrity sha512-HbjwKeC+pHUFBfLMNzuSjqFE/58+rLVKmOU3lxQrpsxLBOGosYco/Q0GduBb0/jEMRiyEqjNT/01rRdOMWq5pw== - dependencies: - "@docusaurus/babel" "3.9.2" - "@docusaurus/bundler" "3.9.2" - "@docusaurus/logger" "3.9.2" - "@docusaurus/mdx-loader" "3.9.2" - "@docusaurus/utils" "3.9.2" - "@docusaurus/utils-common" "3.9.2" - "@docusaurus/utils-validation" "3.9.2" + webpackbar "^7.0.0" + +"@docusaurus/core@3.10.1", "@docusaurus/core@^3.10.1": + version "3.10.1" + resolved "https://registry.yarnpkg.com/@docusaurus/core/-/core-3.10.1.tgz#3f8bdb97451b4df14f2a3b39ab0186366fbf8fbe" + integrity sha512-3pf2fXXw0eVk8WnC3T4LIigRDupcpvngpKo9Vy7mYyBhuddc0klDUuZAIfzMoK6z05pdlk6EFC/vBSX43+1O5w== + dependencies: + "@docusaurus/babel" "3.10.1" + "@docusaurus/bundler" "3.10.1" + "@docusaurus/logger" "3.10.1" + "@docusaurus/mdx-loader" "3.10.1" + "@docusaurus/utils" "3.10.1" + "@docusaurus/utils-common" "3.10.1" + "@docusaurus/utils-validation" "3.10.1" boxen "^6.2.1" chalk "^4.1.2" chokidar "^3.5.3" @@ -1738,7 +1750,7 @@ escape-html "^1.0.3" eta "^2.2.0" eval "^0.1.8" - execa "5.1.1" + execa "^5.1.1" fs-extra "^11.1.1" html-tags "^3.3.1" html-webpack-plugin "^5.6.0" @@ -1749,12 +1761,12 @@ prompts "^2.4.2" react-helmet-async "npm:@slorber/react-helmet-async@1.3.0" react-loadable "npm:@docusaurus/react-loadable@6.0.0" - react-loadable-ssr-addon-v5-slorber "^1.0.1" + react-loadable-ssr-addon-v5-slorber "^1.0.3" react-router "^5.3.4" react-router-config "^5.1.1" react-router-dom "^5.3.4" semver "^7.5.4" - serve-handler "^6.1.6" + serve-handler "^6.1.7" tinypool "^1.0.2" tslib "^2.6.0" update-notifier "^6.0.2" @@ -1763,27 +1775,28 @@ webpack-dev-server "^5.2.2" webpack-merge "^6.0.1" -"@docusaurus/cssnano-preset@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/cssnano-preset/-/cssnano-preset-3.9.2.tgz#523aab65349db3c51a77f2489048d28527759428" - integrity sha512-8gBKup94aGttRduABsj7bpPFTX7kbwu+xh3K9NMCF5K4bWBqTFYW+REKHF6iBVDHRJ4grZdIPbvkiHd/XNKRMQ== +"@docusaurus/cssnano-preset@3.10.1": + version "3.10.1" + resolved "https://registry.yarnpkg.com/@docusaurus/cssnano-preset/-/cssnano-preset-3.10.1.tgz#4b6bafeca8bb9423364d2fd6683c28e2f85a4665" + integrity sha512-eNfHGcTKCSq6xmcavAkX3RRclHaE2xRCMParlDXLdXVP01/a2e/jKXMj/0ULnLFQSNwwuI62L0Ge8J+nZsR7UQ== dependencies: cssnano-preset-advanced "^6.1.2" postcss "^8.5.4" postcss-sort-media-queries "^5.2.0" tslib "^2.6.0" -"@docusaurus/faster@^3.8.1": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/faster/-/faster-3.9.2.tgz#47b69f39ed935fdcc8dc03896274fca29056e962" - integrity sha512-DEVIwhbrZZ4ir31X+qQNEQqDWkgCJUV6kiPPAd2MGTY8n5/n0c4B8qA5k1ipF2izwH00JEf0h6Daaut71zzkyw== +"@docusaurus/faster@^3.10.1": + version "3.10.1" + resolved "https://registry.yarnpkg.com/@docusaurus/faster/-/faster-3.10.1.tgz#a63d89ae980c98e1eeab3ff15ee083f7c20ed353" + integrity sha512-XTZhE5C1gZ/DaYYMlSk02dwP5vhpQON5QHVz1s3892mSESAywgWanURpXEDAvt4GvGuq7s+XP8rTWHZvfaJmdQ== dependencies: - "@docusaurus/types" "3.9.2" - "@rspack/core" "^1.5.0" + "@docusaurus/types" "3.10.1" + "@rspack/core" "^1.7.10" "@swc/core" "^1.7.39" "@swc/html" "^1.13.5" browserslist "^4.24.2" lightningcss "^1.27.0" + semver "^7.5.4" swc-loader "^0.2.6" tslib "^2.6.0" webpack "^5.95.0" @@ -1796,45 +1809,7 @@ chalk "^4.1.2" tslib "^2.6.0" -"@docusaurus/logger@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/logger/-/logger-3.9.2.tgz#6ec6364b90f5a618a438cc9fd01ac7376869f92a" - integrity sha512-/SVCc57ByARzGSU60c50rMyQlBuMIJCjcsJlkphxY6B0GV4UH3tcA1994N8fFfbJ9kX3jIBe/xg3XP5qBtGDbA== - dependencies: - chalk "^4.1.2" - tslib "^2.6.0" - -"@docusaurus/mdx-loader@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/mdx-loader/-/mdx-loader-3.9.2.tgz#78d238de6c6203fa811cc2a7e90b9b79e111408c" - integrity sha512-wiYoGwF9gdd6rev62xDU8AAM8JuLI/hlwOtCzMmYcspEkzecKrP8J8X+KpYnTlACBUUtXNJpSoCwFWJhLRevzQ== - dependencies: - "@docusaurus/logger" "3.9.2" - "@docusaurus/utils" "3.9.2" - "@docusaurus/utils-validation" "3.9.2" - "@mdx-js/mdx" "^3.0.0" - "@slorber/remark-comment" "^1.0.0" - escape-html "^1.0.3" - estree-util-value-to-estree "^3.0.1" - file-loader "^6.2.0" - fs-extra "^11.1.1" - image-size "^2.0.2" - mdast-util-mdx "^3.0.0" - mdast-util-to-string "^4.0.0" - rehype-raw "^7.0.0" - remark-directive "^3.0.0" - remark-emoji "^4.0.0" - remark-frontmatter "^5.0.0" - remark-gfm "^4.0.0" - stringify-object "^3.3.0" - tslib "^2.6.0" - unified "^11.0.3" - unist-util-visit "^5.0.0" - url-loader "^4.1.1" - vfile "^6.0.1" - webpack "^5.88.1" - -"@docusaurus/mdx-loader@^3.10.1": +"@docusaurus/mdx-loader@3.10.1", "@docusaurus/mdx-loader@^3.10.1": version "3.10.1" resolved "https://registry.yarnpkg.com/@docusaurus/mdx-loader/-/mdx-loader-3.10.1.tgz#050ae9bc614158a4ec07a628aa75fa9ae90d7e82" integrity sha512-GRmeb/wQ+iXRrFwcHBfgQhrJxGElgCsoTWZYDhccjsZVne1p8MK/EpQVIloXttz76TCe78kKD5AEG9n1xc1oxQ== @@ -1864,20 +1839,7 @@ vfile "^6.0.1" webpack "^5.88.1" -"@docusaurus/module-type-aliases@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/module-type-aliases/-/module-type-aliases-3.9.2.tgz#993c7cb0114363dea5ef6855e989b3ad4b843a34" - integrity sha512-8qVe2QA9hVLzvnxP46ysuofJUIc/yYQ82tvA/rBTrnpXtCjNSFLxEZfd5U8cYZuJIVlkPxamsIgwd5tGZXfvew== - dependencies: - "@docusaurus/types" "3.9.2" - "@types/history" "^4.7.11" - "@types/react" "*" - "@types/react-router-config" "*" - "@types/react-router-dom" "*" - react-helmet-async "npm:@slorber/react-helmet-async@1.3.0" - react-loadable "npm:@docusaurus/react-loadable@6.0.0" - -"@docusaurus/module-type-aliases@^3.10.1": +"@docusaurus/module-type-aliases@3.10.1", "@docusaurus/module-type-aliases@^3.10.1": version "3.10.1" resolved "https://registry.yarnpkg.com/@docusaurus/module-type-aliases/-/module-type-aliases-3.10.1.tgz#22d39177c296786eb6e0d940699cd590cc93ca77" integrity sha512-YoOZKUdGlp8xSYhuAkGdSo5Ydkbq4V4eK3sD8v0a2hloxCWdQbNBhkc+Ko9QyjpESc0BYcIGM5iHVAy5hdFV6w== @@ -1890,20 +1852,21 @@ react-helmet-async "npm:@slorber/react-helmet-async@1.3.0" react-loadable "npm:@docusaurus/react-loadable@6.0.0" -"@docusaurus/plugin-content-blog@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/plugin-content-blog/-/plugin-content-blog-3.9.2.tgz#d5ce51eb7757bdab0515e2dd26a793ed4e119df9" - integrity sha512-3I2HXy3L1QcjLJLGAoTvoBnpOwa6DPUa3Q0dMK19UTY9mhPkKQg/DYhAGTiBUKcTR0f08iw7kLPqOhIgdV3eVQ== - dependencies: - "@docusaurus/core" "3.9.2" - "@docusaurus/logger" "3.9.2" - "@docusaurus/mdx-loader" "3.9.2" - "@docusaurus/theme-common" "3.9.2" - "@docusaurus/types" "3.9.2" - "@docusaurus/utils" "3.9.2" - "@docusaurus/utils-common" "3.9.2" - "@docusaurus/utils-validation" "3.9.2" +"@docusaurus/plugin-content-blog@3.10.1": + version "3.10.1" + resolved "https://registry.yarnpkg.com/@docusaurus/plugin-content-blog/-/plugin-content-blog-3.10.1.tgz#0bd8de700ccbd8e95d920df2613304ef59abe72b" + integrity sha512-mmkgE6Q2+K74tnkou7tXlpDLvoCU/qkSa2GSQ3XUiHWvcebCoDQzS670RR3tO8PmaWlIyWWISYWzZLuMfxunRA== + dependencies: + "@docusaurus/core" "3.10.1" + "@docusaurus/logger" "3.10.1" + "@docusaurus/mdx-loader" "3.10.1" + "@docusaurus/theme-common" "3.10.1" + "@docusaurus/types" "3.10.1" + "@docusaurus/utils" "3.10.1" + "@docusaurus/utils-common" "3.10.1" + "@docusaurus/utils-validation" "3.10.1" cheerio "1.0.0-rc.12" + combine-promises "^1.1.0" feed "^4.2.2" fs-extra "^11.1.1" lodash "^4.17.21" @@ -1914,20 +1877,20 @@ utility-types "^3.10.0" webpack "^5.88.1" -"@docusaurus/plugin-content-docs@3.9.2", "@docusaurus/plugin-content-docs@^3.8.1": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/plugin-content-docs/-/plugin-content-docs-3.9.2.tgz#cd8f2d1c06e53c3fa3d24bdfcb48d237bf2d6b2e" - integrity sha512-C5wZsGuKTY8jEYsqdxhhFOe1ZDjH0uIYJ9T/jebHwkyxqnr4wW0jTkB72OMqNjsoQRcb0JN3PcSeTwFlVgzCZg== - dependencies: - "@docusaurus/core" "3.9.2" - "@docusaurus/logger" "3.9.2" - "@docusaurus/mdx-loader" "3.9.2" - "@docusaurus/module-type-aliases" "3.9.2" - "@docusaurus/theme-common" "3.9.2" - "@docusaurus/types" "3.9.2" - "@docusaurus/utils" "3.9.2" - "@docusaurus/utils-common" "3.9.2" - "@docusaurus/utils-validation" "3.9.2" +"@docusaurus/plugin-content-docs@3.10.1", "@docusaurus/plugin-content-docs@^3.10.1": + version "3.10.1" + resolved "https://registry.yarnpkg.com/@docusaurus/plugin-content-docs/-/plugin-content-docs-3.10.1.tgz#261e0e982e4a937c05b462e3c5729374f433b752" + integrity sha512-2jRVrtzjf8LClGTHQlwlwuD3wQXRx3WEoF7XUarJ8Ou+0onV+SLtejsyfY9JLpfUh9hPhXM4pbBGkyAY4Bi3HQ== + dependencies: + "@docusaurus/core" "3.10.1" + "@docusaurus/logger" "3.10.1" + "@docusaurus/mdx-loader" "3.10.1" + "@docusaurus/module-type-aliases" "3.10.1" + "@docusaurus/theme-common" "3.10.1" + "@docusaurus/types" "3.10.1" + "@docusaurus/utils" "3.10.1" + "@docusaurus/utils-common" "3.10.1" + "@docusaurus/utils-validation" "3.10.1" "@types/react-router-config" "^5.0.7" combine-promises "^1.1.0" fs-extra "^11.1.1" @@ -1938,144 +1901,145 @@ utility-types "^3.10.0" webpack "^5.88.1" -"@docusaurus/plugin-content-pages@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/plugin-content-pages/-/plugin-content-pages-3.9.2.tgz#22db6c88ade91cec0a9e87a00b8089898051b08d" - integrity sha512-s4849w/p4noXUrGpPUF0BPqIAfdAe76BLaRGAGKZ1gTDNiGxGcpsLcwJ9OTi1/V8A+AzvsmI9pkjie2zjIQZKA== +"@docusaurus/plugin-content-pages@3.10.1": + version "3.10.1" + resolved "https://registry.yarnpkg.com/@docusaurus/plugin-content-pages/-/plugin-content-pages-3.10.1.tgz#8c6ffc2079ed0262548ecc4df1dea6add6aa9673" + integrity sha512-huJpaRPMl42nsFwuCXvV8bVDj2MazuwRJIUylI/RSlmZeJssVoZXeCjVf1y+1Drtpa9SKcdGn8yoJ76IRJijtw== dependencies: - "@docusaurus/core" "3.9.2" - "@docusaurus/mdx-loader" "3.9.2" - "@docusaurus/types" "3.9.2" - "@docusaurus/utils" "3.9.2" - "@docusaurus/utils-validation" "3.9.2" + "@docusaurus/core" "3.10.1" + "@docusaurus/mdx-loader" "3.10.1" + "@docusaurus/types" "3.10.1" + "@docusaurus/utils" "3.10.1" + "@docusaurus/utils-validation" "3.10.1" fs-extra "^11.1.1" tslib "^2.6.0" webpack "^5.88.1" -"@docusaurus/plugin-css-cascade-layers@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/plugin-css-cascade-layers/-/plugin-css-cascade-layers-3.9.2.tgz#358c85f63f1c6a11f611f1b8889d9435c11b22f8" - integrity sha512-w1s3+Ss+eOQbscGM4cfIFBlVg/QKxyYgj26k5AnakuHkKxH6004ZtuLe5awMBotIYF2bbGDoDhpgQ4r/kcj4rQ== +"@docusaurus/plugin-css-cascade-layers@3.10.1": + version "3.10.1" + resolved "https://registry.yarnpkg.com/@docusaurus/plugin-css-cascade-layers/-/plugin-css-cascade-layers-3.10.1.tgz#440578d95cbe1a6120936fa83df868d2626cd1d8" + integrity sha512-r//fn+MNHkE1wCof8T29VAQezt1enGCpsFxoziBbvLgBM4JfXN2P3rxrBaavHmvLvm7lYkpJeitcDthwnmWCTw== dependencies: - "@docusaurus/core" "3.9.2" - "@docusaurus/types" "3.9.2" - "@docusaurus/utils" "3.9.2" - "@docusaurus/utils-validation" "3.9.2" + "@docusaurus/core" "3.10.1" + "@docusaurus/types" "3.10.1" + "@docusaurus/utils" "3.10.1" + "@docusaurus/utils-validation" "3.10.1" tslib "^2.6.0" -"@docusaurus/plugin-debug@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/plugin-debug/-/plugin-debug-3.9.2.tgz#b5df4db115583f5404a252dbf66f379ff933e53c" - integrity sha512-j7a5hWuAFxyQAkilZwhsQ/b3T7FfHZ+0dub6j/GxKNFJp2h9qk/P1Bp7vrGASnvA9KNQBBL1ZXTe7jlh4VdPdA== +"@docusaurus/plugin-debug@3.10.1": + version "3.10.1" + resolved "https://registry.yarnpkg.com/@docusaurus/plugin-debug/-/plugin-debug-3.10.1.tgz#b8b7b24d9a7d185fd8a56a030f90145d3bfd8239" + integrity sha512-9KqOpKNfAyqGZykRb9LhIT/vyRF6sm/ykhjj/39JvaJahDS+jZJE0Z1Wfz9q3DUNDTMNN0Q7u/kk4rKKU+IJuA== dependencies: - "@docusaurus/core" "3.9.2" - "@docusaurus/types" "3.9.2" - "@docusaurus/utils" "3.9.2" + "@docusaurus/core" "3.10.1" + "@docusaurus/types" "3.10.1" + "@docusaurus/utils" "3.10.1" fs-extra "^11.1.1" react-json-view-lite "^2.3.0" tslib "^2.6.0" -"@docusaurus/plugin-google-analytics@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/plugin-google-analytics/-/plugin-google-analytics-3.9.2.tgz#857fe075fdeccdf6959e62954d9efe39769fa247" - integrity sha512-mAwwQJ1Us9jL/lVjXtErXto4p4/iaLlweC54yDUK1a97WfkC6Z2k5/769JsFgwOwOP+n5mUQGACXOEQ0XDuVUw== +"@docusaurus/plugin-google-analytics@3.10.1": + version "3.10.1" + resolved "https://registry.yarnpkg.com/@docusaurus/plugin-google-analytics/-/plugin-google-analytics-3.10.1.tgz#ac15afc77386e0352edb8a1698d993aa5de36ffc" + integrity sha512-8o0P1KtmgdYQHH+oInitPpRWI0Of5XednAX4+DMhQNSmGSRNrsEEHg1ebv35m9AgRClfAytCJ5jA9KvcASTyuA== dependencies: - "@docusaurus/core" "3.9.2" - "@docusaurus/types" "3.9.2" - "@docusaurus/utils-validation" "3.9.2" + "@docusaurus/core" "3.10.1" + "@docusaurus/types" "3.10.1" + "@docusaurus/utils-validation" "3.10.1" tslib "^2.6.0" -"@docusaurus/plugin-google-gtag@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/plugin-google-gtag/-/plugin-google-gtag-3.9.2.tgz#df75b1a90ae9266b0471909ba0265f46d5dcae62" - integrity sha512-YJ4lDCphabBtw19ooSlc1MnxtYGpjFV9rEdzjLsUnBCeis2djUyCozZaFhCg6NGEwOn7HDDyMh0yzcdRpnuIvA== +"@docusaurus/plugin-google-gtag@3.10.1": + version "3.10.1" + resolved "https://registry.yarnpkg.com/@docusaurus/plugin-google-gtag/-/plugin-google-gtag-3.10.1.tgz#0482b83b9bc411aa99a432be2b39d2e53a00e2e0" + integrity sha512-pu3xIUo5o/zCMLfUY9BO5KOwSH0zIsAGyFRPvXHayFSA5XIhCU/SFuB0g0ZNjFn9niZLCaNvoeAuOGFJZq0fdw== dependencies: - "@docusaurus/core" "3.9.2" - "@docusaurus/types" "3.9.2" - "@docusaurus/utils-validation" "3.9.2" - "@types/gtag.js" "^0.0.12" + "@docusaurus/core" "3.10.1" + "@docusaurus/types" "3.10.1" + "@docusaurus/utils-validation" "3.10.1" + "@types/gtag.js" "^0.0.20" tslib "^2.6.0" -"@docusaurus/plugin-google-tag-manager@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/plugin-google-tag-manager/-/plugin-google-tag-manager-3.9.2.tgz#d1a3cf935acb7d31b84685e92d70a1d342946677" - integrity sha512-LJtIrkZN/tuHD8NqDAW1Tnw0ekOwRTfobWPsdO15YxcicBo2ykKF0/D6n0vVBfd3srwr9Z6rzrIWYrMzBGrvNw== +"@docusaurus/plugin-google-tag-manager@3.10.1": + version "3.10.1" + resolved "https://registry.yarnpkg.com/@docusaurus/plugin-google-tag-manager/-/plugin-google-tag-manager-3.10.1.tgz#eaf5765d6f82b4fb661d92a793d1883f9d1ec106" + integrity sha512-f6fyGHiCm7kJHBtAisGQS5oNBnpnMTYQZxDXeVrnw/3zWU+LMA22pr6UHGYkBKDbN+qPC5QHG3NuOfzQLq3+Lw== dependencies: - "@docusaurus/core" "3.9.2" - "@docusaurus/types" "3.9.2" - "@docusaurus/utils-validation" "3.9.2" + "@docusaurus/core" "3.10.1" + "@docusaurus/types" "3.10.1" + "@docusaurus/utils-validation" "3.10.1" tslib "^2.6.0" -"@docusaurus/plugin-sitemap@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/plugin-sitemap/-/plugin-sitemap-3.9.2.tgz#e1d9f7012942562cc0c6543d3cb2cdc4ae713dc4" - integrity sha512-WLh7ymgDXjG8oPoM/T4/zUP7KcSuFYRZAUTl8vR6VzYkfc18GBM4xLhcT+AKOwun6kBivYKUJf+vlqYJkm+RHw== - dependencies: - "@docusaurus/core" "3.9.2" - "@docusaurus/logger" "3.9.2" - "@docusaurus/types" "3.9.2" - "@docusaurus/utils" "3.9.2" - "@docusaurus/utils-common" "3.9.2" - "@docusaurus/utils-validation" "3.9.2" +"@docusaurus/plugin-sitemap@3.10.1": + version "3.10.1" + resolved "https://registry.yarnpkg.com/@docusaurus/plugin-sitemap/-/plugin-sitemap-3.10.1.tgz#66a6974bb2fd1b9d8f5cb0f3c5ecd2201c118565" + integrity sha512-C26MbmmqgdjkDq1htaZ3aD7LzEDKFWXfpyQpt0EOUThuq5nV77zDaedV20yHcVo9p+3ey9aZ4pbHA0D3QcZTzg== + dependencies: + "@docusaurus/core" "3.10.1" + "@docusaurus/logger" "3.10.1" + "@docusaurus/types" "3.10.1" + "@docusaurus/utils" "3.10.1" + "@docusaurus/utils-common" "3.10.1" + "@docusaurus/utils-validation" "3.10.1" fs-extra "^11.1.1" sitemap "^7.1.1" tslib "^2.6.0" -"@docusaurus/plugin-svgr@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/plugin-svgr/-/plugin-svgr-3.9.2.tgz#62857ed79d97c0150d25f7e7380fdee65671163a" - integrity sha512-n+1DE+5b3Lnf27TgVU5jM1d4x5tUh2oW5LTsBxJX4PsAPV0JGcmI6p3yLYtEY0LRVEIJh+8RsdQmRE66wSV8mw== +"@docusaurus/plugin-svgr@3.10.1": + version "3.10.1" + resolved "https://registry.yarnpkg.com/@docusaurus/plugin-svgr/-/plugin-svgr-3.10.1.tgz#c217c24d6d23fd2bc6f54d44c040635b49d6b36e" + integrity sha512-6SFxsmjWFkVLDmBUvFK6i72QjUwqyQFe4Ovz+SUJophJjOyVG3ZZG5IQpBC/kX/Gfv1yWeU9nWauH6F6Q7QX/Q== dependencies: - "@docusaurus/core" "3.9.2" - "@docusaurus/types" "3.9.2" - "@docusaurus/utils" "3.9.2" - "@docusaurus/utils-validation" "3.9.2" + "@docusaurus/core" "3.10.1" + "@docusaurus/types" "3.10.1" + "@docusaurus/utils" "3.10.1" + "@docusaurus/utils-validation" "3.10.1" "@svgr/core" "8.1.0" "@svgr/webpack" "^8.1.0" tslib "^2.6.0" webpack "^5.88.1" -"@docusaurus/preset-classic@^3.8.1": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/preset-classic/-/preset-classic-3.9.2.tgz#85cc4f91baf177f8146c9ce896dfa1f0fd377050" - integrity sha512-IgyYO2Gvaigi21LuDIe+nvmN/dfGXAiMcV/murFqcpjnZc7jxFAxW+9LEjdPt61uZLxG4ByW/oUmX/DDK9t/8w== - dependencies: - "@docusaurus/core" "3.9.2" - "@docusaurus/plugin-content-blog" "3.9.2" - "@docusaurus/plugin-content-docs" "3.9.2" - "@docusaurus/plugin-content-pages" "3.9.2" - "@docusaurus/plugin-css-cascade-layers" "3.9.2" - "@docusaurus/plugin-debug" "3.9.2" - "@docusaurus/plugin-google-analytics" "3.9.2" - "@docusaurus/plugin-google-gtag" "3.9.2" - "@docusaurus/plugin-google-tag-manager" "3.9.2" - "@docusaurus/plugin-sitemap" "3.9.2" - "@docusaurus/plugin-svgr" "3.9.2" - "@docusaurus/theme-classic" "3.9.2" - "@docusaurus/theme-common" "3.9.2" - "@docusaurus/theme-search-algolia" "3.9.2" - "@docusaurus/types" "3.9.2" - -"@docusaurus/theme-classic@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/theme-classic/-/theme-classic-3.9.2.tgz#6e514f99a0ff42b80afcf42d5e5d042618311ce0" - integrity sha512-IGUsArG5hhekXd7RDb11v94ycpJpFdJPkLnt10fFQWOVxAtq5/D7hT6lzc2fhyQKaaCE62qVajOMKL7OiAFAIA== - dependencies: - "@docusaurus/core" "3.9.2" - "@docusaurus/logger" "3.9.2" - "@docusaurus/mdx-loader" "3.9.2" - "@docusaurus/module-type-aliases" "3.9.2" - "@docusaurus/plugin-content-blog" "3.9.2" - "@docusaurus/plugin-content-docs" "3.9.2" - "@docusaurus/plugin-content-pages" "3.9.2" - "@docusaurus/theme-common" "3.9.2" - "@docusaurus/theme-translations" "3.9.2" - "@docusaurus/types" "3.9.2" - "@docusaurus/utils" "3.9.2" - "@docusaurus/utils-common" "3.9.2" - "@docusaurus/utils-validation" "3.9.2" +"@docusaurus/preset-classic@^3.10.1": + version "3.10.1" + resolved "https://registry.yarnpkg.com/@docusaurus/preset-classic/-/preset-classic-3.10.1.tgz#faf330d96aedc9083a59bec09d966ae4dfc8b2fb" + integrity sha512-YO/FL8v1zmbxoTso6mjMz/RDjhaTJxb1UpFFTDdY5847LLDCeyYiYlrhyTbgN1RIN3xnkLKZ9Lj1x8hUzI4JOg== + dependencies: + "@docusaurus/core" "3.10.1" + "@docusaurus/plugin-content-blog" "3.10.1" + "@docusaurus/plugin-content-docs" "3.10.1" + "@docusaurus/plugin-content-pages" "3.10.1" + "@docusaurus/plugin-css-cascade-layers" "3.10.1" + "@docusaurus/plugin-debug" "3.10.1" + "@docusaurus/plugin-google-analytics" "3.10.1" + "@docusaurus/plugin-google-gtag" "3.10.1" + "@docusaurus/plugin-google-tag-manager" "3.10.1" + "@docusaurus/plugin-sitemap" "3.10.1" + "@docusaurus/plugin-svgr" "3.10.1" + "@docusaurus/theme-classic" "3.10.1" + "@docusaurus/theme-common" "3.10.1" + "@docusaurus/theme-search-algolia" "3.10.1" + "@docusaurus/types" "3.10.1" + +"@docusaurus/theme-classic@3.10.1": + version "3.10.1" + resolved "https://registry.yarnpkg.com/@docusaurus/theme-classic/-/theme-classic-3.10.1.tgz#deed8cf73cc0f56113e53775cbb3b168c3c61566" + integrity sha512-VU1RK0qb2pab0si4r7HFK37cYco8VzqLj3u1PspVipSr/z/GPVKHO4/HXbnePqHoWDk8urjyGSeatH0NIMBM1A== + dependencies: + "@docusaurus/core" "3.10.1" + "@docusaurus/logger" "3.10.1" + "@docusaurus/mdx-loader" "3.10.1" + "@docusaurus/module-type-aliases" "3.10.1" + "@docusaurus/plugin-content-blog" "3.10.1" + "@docusaurus/plugin-content-docs" "3.10.1" + "@docusaurus/plugin-content-pages" "3.10.1" + "@docusaurus/theme-common" "3.10.1" + "@docusaurus/theme-translations" "3.10.1" + "@docusaurus/types" "3.10.1" + "@docusaurus/utils" "3.10.1" + "@docusaurus/utils-common" "3.10.1" + "@docusaurus/utils-validation" "3.10.1" "@mdx-js/react" "^3.0.0" clsx "^2.0.0" + copy-text-to-clipboard "^3.2.0" infima "0.2.0-alpha.45" lodash "^4.17.21" nprogress "^0.2.0" @@ -2087,15 +2051,15 @@ tslib "^2.6.0" utility-types "^3.10.0" -"@docusaurus/theme-common@3.9.2", "@docusaurus/theme-common@^3.8.1": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/theme-common/-/theme-common-3.9.2.tgz#487172c6fef9815c2746ef62a71e4f5b326f9ba5" - integrity sha512-6c4DAbR6n6nPbnZhY2V3tzpnKnGL+6aOsLvFL26VRqhlczli9eWG0VDUNoCQEPnGwDMhPS42UhSAnz5pThm5Ag== +"@docusaurus/theme-common@3.10.1", "@docusaurus/theme-common@^3.10.1": + version "3.10.1" + resolved "https://registry.yarnpkg.com/@docusaurus/theme-common/-/theme-common-3.10.1.tgz#cbfec82b1b107be5c229811ed9caae14a501361c" + integrity sha512-0YtmIeoNo1fIw65LO8+/1dPgmDV86UmhMkow37gzjytuiCSQm9xob6PJy0L4kuQEMTLfUOGvkXvZr7GPrHquMA== dependencies: - "@docusaurus/mdx-loader" "3.9.2" - "@docusaurus/module-type-aliases" "3.9.2" - "@docusaurus/utils" "3.9.2" - "@docusaurus/utils-common" "3.9.2" + "@docusaurus/mdx-loader" "3.10.1" + "@docusaurus/module-type-aliases" "3.10.1" + "@docusaurus/utils" "3.10.1" + "@docusaurus/utils-common" "3.10.1" "@types/history" "^4.7.11" "@types/react" "*" "@types/react-router-config" "*" @@ -2105,19 +2069,20 @@ tslib "^2.6.0" utility-types "^3.10.0" -"@docusaurus/theme-search-algolia@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/theme-search-algolia/-/theme-search-algolia-3.9.2.tgz#420fd5b27fc1673b48151fdc9fe7167ba135ed50" - integrity sha512-GBDSFNwjnh5/LdkxCKQHkgO2pIMX1447BxYUBG2wBiajS21uj64a+gH/qlbQjDLxmGrbrllBrtJkUHxIsiwRnw== - dependencies: - "@docsearch/react" "^3.9.0 || ^4.1.0" - "@docusaurus/core" "3.9.2" - "@docusaurus/logger" "3.9.2" - "@docusaurus/plugin-content-docs" "3.9.2" - "@docusaurus/theme-common" "3.9.2" - "@docusaurus/theme-translations" "3.9.2" - "@docusaurus/utils" "3.9.2" - "@docusaurus/utils-validation" "3.9.2" +"@docusaurus/theme-search-algolia@3.10.1": + version "3.10.1" + resolved "https://registry.yarnpkg.com/@docusaurus/theme-search-algolia/-/theme-search-algolia-3.10.1.tgz#6f422058711629ce8d7c2f17e1e54efa075c626e" + integrity sha512-OTaARARVZj2GvkJQjB+1jOIxntRaXea+G+fMsNqrZBAU1O1vJKDW22R7kECOHW27oJCLFN9HKaZeRrfAUyviug== + dependencies: + "@algolia/autocomplete-core" "^1.19.2" + "@docsearch/react" "^3.9.0 || ^4.3.2" + "@docusaurus/core" "3.10.1" + "@docusaurus/logger" "3.10.1" + "@docusaurus/plugin-content-docs" "3.10.1" + "@docusaurus/theme-common" "3.10.1" + "@docusaurus/theme-translations" "3.10.1" + "@docusaurus/utils" "3.10.1" + "@docusaurus/utils-validation" "3.10.1" algoliasearch "^5.37.0" algoliasearch-helper "^3.26.0" clsx "^2.0.0" @@ -2127,15 +2092,15 @@ tslib "^2.6.0" utility-types "^3.10.0" -"@docusaurus/theme-translations@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/theme-translations/-/theme-translations-3.9.2.tgz#238cd69c2da92d612be3d3b4f95944c1d0f1e041" - integrity sha512-vIryvpP18ON9T9rjgMRFLr2xJVDpw1rtagEGf8Ccce4CkTrvM/fRB8N2nyWYOW5u3DdjkwKw5fBa+3tbn9P4PA== +"@docusaurus/theme-translations@3.10.1": + version "3.10.1" + resolved "https://registry.yarnpkg.com/@docusaurus/theme-translations/-/theme-translations-3.10.1.tgz#c3119a015652290eea560ca45ac775963d6eb75b" + integrity sha512-cLMyaKivjBVWKMJuWqyFVVgtqe8DPJNPkog0bn8W1MDVAKcPdxRFycBfC1We1RaNp7Rdk513bmtW78RR6OBxBw== dependencies: fs-extra "^11.1.1" tslib "^2.6.0" -"@docusaurus/types@3.10.1", "@docusaurus/types@^3.8.1": +"@docusaurus/types@3.10.1", "@docusaurus/types@^3.10.1": version "3.10.1" resolved "https://registry.yarnpkg.com/@docusaurus/types/-/types-3.10.1.tgz#d42837938ae43ca2be0ca47e63e00476b5eb94be" integrity sha512-XYMK8k1szDCFMw2V+Xyen0g7Kee1sP3dtFnl7vkGkZOkeAJ/oPDQPL8iz4HBKOo/cwU8QeV6onVjMqtP+tFzsw== @@ -2151,22 +2116,6 @@ webpack "^5.95.0" webpack-merge "^5.9.0" -"@docusaurus/types@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/types/-/types-3.9.2.tgz#e482cf18faea0d1fa5ce0e3f1e28e0f32d2593eb" - integrity sha512-Ux1JUNswg+EfUEmajJjyhIohKceitY/yzjRUpu04WXgvVz+fbhVC0p+R0JhvEu4ytw8zIAys2hrdpQPBHRIa8Q== - dependencies: - "@mdx-js/mdx" "^3.0.0" - "@types/history" "^4.7.11" - "@types/mdast" "^4.0.2" - "@types/react" "*" - commander "^5.1.0" - joi "^17.9.2" - react-helmet-async "npm:@slorber/react-helmet-async@1.3.0" - utility-types "^3.10.0" - webpack "^5.95.0" - webpack-merge "^5.9.0" - "@docusaurus/utils-common@3.10.1": version "3.10.1" resolved "https://registry.yarnpkg.com/@docusaurus/utils-common/-/utils-common-3.10.1.tgz#6350b4898691e765de750f90eade0e0fa7902d99" @@ -2175,14 +2124,6 @@ "@docusaurus/types" "3.10.1" tslib "^2.6.0" -"@docusaurus/utils-common@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/utils-common/-/utils-common-3.9.2.tgz#e89bfcf43d66359f43df45293fcdf22814847460" - integrity sha512-I53UC1QctruA6SWLvbjbhCpAw7+X7PePoe5pYcwTOEXD/PxeP8LnECAhTHHwWCblyUX5bMi4QLRkxvyZ+IT8Aw== - dependencies: - "@docusaurus/types" "3.9.2" - tslib "^2.6.0" - "@docusaurus/utils-validation@3.10.1": version "3.10.1" resolved "https://registry.yarnpkg.com/@docusaurus/utils-validation/-/utils-validation-3.10.1.tgz#ddbcce997a5506424cdd16abf6845cc51692acae" @@ -2197,20 +2138,6 @@ lodash "^4.17.21" tslib "^2.6.0" -"@docusaurus/utils-validation@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/utils-validation/-/utils-validation-3.9.2.tgz#04aec285604790806e2fc5aa90aa950dc7ba75ae" - integrity sha512-l7yk3X5VnNmATbwijJkexdhulNsQaNDwoagiwujXoxFbWLcxHQqNQ+c/IAlzrfMMOfa/8xSBZ7KEKDesE/2J7A== - dependencies: - "@docusaurus/logger" "3.9.2" - "@docusaurus/utils" "3.9.2" - "@docusaurus/utils-common" "3.9.2" - fs-extra "^11.2.0" - joi "^17.9.2" - js-yaml "^4.1.0" - lodash "^4.17.21" - tslib "^2.6.0" - "@docusaurus/utils@3.10.1": version "3.10.1" resolved "https://registry.yarnpkg.com/@docusaurus/utils/-/utils-3.10.1.tgz#535968caa2c9bff69f997a081b98b95b3c5d3785" @@ -2238,33 +2165,6 @@ utility-types "^3.10.0" webpack "^5.88.1" -"@docusaurus/utils@3.9.2": - version "3.9.2" - resolved "https://registry.yarnpkg.com/@docusaurus/utils/-/utils-3.9.2.tgz#ffab7922631c7e0febcb54e6d499f648bf8a89eb" - integrity sha512-lBSBiRruFurFKXr5Hbsl2thmGweAPmddhF3jb99U4EMDA5L+e5Y1rAkOS07Nvrup7HUMBDrCV45meaxZnt28nQ== - dependencies: - "@docusaurus/logger" "3.9.2" - "@docusaurus/types" "3.9.2" - "@docusaurus/utils-common" "3.9.2" - escape-string-regexp "^4.0.0" - execa "5.1.1" - file-loader "^6.2.0" - fs-extra "^11.1.1" - github-slugger "^1.5.0" - globby "^11.1.0" - gray-matter "^4.0.3" - jiti "^1.20.0" - js-yaml "^4.1.0" - lodash "^4.17.21" - micromatch "^4.0.5" - p-queue "^6.6.2" - prompts "^2.4.2" - resolve-pathname "^3.0.0" - tslib "^2.6.0" - url-loader "^4.1.1" - utility-types "^3.10.0" - webpack "^5.88.1" - "@dprint/darwin-arm64@0.54.0": version "0.54.0" resolved "https://registry.yarnpkg.com/@dprint/darwin-arm64/-/darwin-arm64-0.54.0.tgz#9230db5eb0f79dca83e92e43dce86a623c9d7844" @@ -3053,81 +2953,81 @@ resolved "https://registry.npmjs.org/@polka/url/-/url-1.0.0-next.29.tgz" integrity sha512-wwQAWhWSuHaag8c4q/KN/vCoeOJYshAIvMQwD4GpSb3OiZklFfvAgmj0VCBBImRpuF/aFgIRzllXlVX93Jevww== -"@rspack/binding-darwin-arm64@1.7.10": - version "1.7.10" - resolved "https://registry.yarnpkg.com/@rspack/binding-darwin-arm64/-/binding-darwin-arm64-1.7.10.tgz#6695cf6da39a2eb346723ec09d5b1f8586f64bd6" - integrity sha512-bsXi7I6TpH+a4L6okIUh1JDvwT+XcK/L7Yvhu5G2t5YYyd2fl5vMM5O9cePRpEb0RdqJZ3Z8i9WIWHap9aQ8Gw== - -"@rspack/binding-darwin-x64@1.7.10": - version "1.7.10" - resolved "https://registry.yarnpkg.com/@rspack/binding-darwin-x64/-/binding-darwin-x64-1.7.10.tgz#8845d616ff8b091250a07e04798346c53cc5c764" - integrity sha512-h/kOGL1bUflDDYnbiUjaRE9kagJpour4FatGihueV03+cRGQ6jpde+BjUakqzMx65CeDbeYI6jAiPhElnlAtRw== - -"@rspack/binding-linux-arm64-gnu@1.7.10": - version "1.7.10" - resolved "https://registry.yarnpkg.com/@rspack/binding-linux-arm64-gnu/-/binding-linux-arm64-gnu-1.7.10.tgz#43f339569715e75201ffa87412456a3ba260908d" - integrity sha512-Z4reus7UxGM4+JuhiIht8KuGP1KgM7nNhOlXUHcQCMswP/Rymj5oJQN3TDWgijFUZs09ULl8t3T+AQAVTd/WvA== - -"@rspack/binding-linux-arm64-musl@1.7.10": - version "1.7.10" - resolved "https://registry.yarnpkg.com/@rspack/binding-linux-arm64-musl/-/binding-linux-arm64-musl-1.7.10.tgz#3c6a22a9d802f99706ff51daecae8ea974546270" - integrity sha512-LYaoVmWizG4oQ3g+St3eM5qxsyfH07kLirP7NJcDMgvu3eQ29MeyTZ3ugkgW6LvlmJue7eTQyf6CZlanoF5SSg== - -"@rspack/binding-linux-x64-gnu@1.7.10": - version "1.7.10" - resolved "https://registry.yarnpkg.com/@rspack/binding-linux-x64-gnu/-/binding-linux-x64-gnu-1.7.10.tgz#822af2900cff8c907fab78d9cdf9004652b32c06" - integrity sha512-aIm2G4Kcm3qxDTNqKarK0oaLY2iXnCmpRQQhAcMlR0aS2LmxL89XzVeRr9GFA1MzGrAsZONWCLkxQvn3WUbm4Q== - -"@rspack/binding-linux-x64-musl@1.7.10": - version "1.7.10" - resolved "https://registry.yarnpkg.com/@rspack/binding-linux-x64-musl/-/binding-linux-x64-musl-1.7.10.tgz#2a698c7984877df2e5f38ddda98983bffbe80c40" - integrity sha512-SIHQbAgB9IPH0H3H+i5rN5jo9yA/yTMq8b7XfRkTMvZ7P7MXxJ0dE8EJu3BmCLM19sqnTc2eX+SVfE8ZMDzghA== - -"@rspack/binding-wasm32-wasi@1.7.10": - version "1.7.10" - resolved "https://registry.yarnpkg.com/@rspack/binding-wasm32-wasi/-/binding-wasm32-wasi-1.7.10.tgz#f906f5b21d8a25547a3d2212a98d078623bdb874" - integrity sha512-J9HDXHD1tj+9FmX4+K3CTkO7dCE2bootlR37YuC2Owc0Lwl1/i2oGT71KHnMqI9faF/hipAaQM5OywkiiuNB7w== +"@rspack/binding-darwin-arm64@1.7.11": + version "1.7.11" + resolved "https://registry.yarnpkg.com/@rspack/binding-darwin-arm64/-/binding-darwin-arm64-1.7.11.tgz#ea43ac25a9ff99a9faf6c820f5d174a32974e95c" + integrity sha512-oduECiZVqbO5zlVw+q7Vy65sJFth99fWPTyucwvLJJtJkPL5n17Uiql2cYP6Ijn0pkqtf1SXgK8WjiKLG5bIig== + +"@rspack/binding-darwin-x64@1.7.11": + version "1.7.11" + resolved "https://registry.yarnpkg.com/@rspack/binding-darwin-x64/-/binding-darwin-x64-1.7.11.tgz#5c724d91559d642d4a5e6aa4ed380c30bd0f64c0" + integrity sha512-a1+TtTE9ap6RalgFi7FGIgkJP6O4Vy6ctv+9WGJy53E4kuqHR0RygzaiVxCI/GMc/vBT9vY23hyrpWb3d1vtXA== + +"@rspack/binding-linux-arm64-gnu@1.7.11": + version "1.7.11" + resolved "https://registry.yarnpkg.com/@rspack/binding-linux-arm64-gnu/-/binding-linux-arm64-gnu-1.7.11.tgz#429119939bbe9d51a72caf99cffb8febe0f870fe" + integrity sha512-P0QrGRPbTWu6RKWfN0bDtbnEps3rXH0MWIMreZABoUrVmNQKtXR6e73J3ub6a+di5s2+K0M2LJ9Bh2/H4UsDUA== + +"@rspack/binding-linux-arm64-musl@1.7.11": + version "1.7.11" + resolved "https://registry.yarnpkg.com/@rspack/binding-linux-arm64-musl/-/binding-linux-arm64-musl-1.7.11.tgz#d939b8c2c5bf35380d3c860402f7063031ef469a" + integrity sha512-6ky7R43VMjWwmx3Yx7Jl7faLBBMAgMDt+/bN35RgwjiPgsIByz65EwytUVuW9rikB43BGHvA/eqlnjLrUzNBqw== + +"@rspack/binding-linux-x64-gnu@1.7.11": + version "1.7.11" + resolved "https://registry.yarnpkg.com/@rspack/binding-linux-x64-gnu/-/binding-linux-x64-gnu-1.7.11.tgz#03567317a7e8cfc62d994dcf9683f932fd22054a" + integrity sha512-cuOJMfCOvb2Wgsry5enXJ3iT1FGUjdPqtGUBVupQlEG4ntSYsQ2PtF4wIDVasR3wdxC5nQbipOrDiN/u6fYsdQ== + +"@rspack/binding-linux-x64-musl@1.7.11": + version "1.7.11" + resolved "https://registry.yarnpkg.com/@rspack/binding-linux-x64-musl/-/binding-linux-x64-musl-1.7.11.tgz#d93c93ea796eae1572b2353a50d58cc6218c53b6" + integrity sha512-CoK37hva4AmHGh3VCsQXmGr40L36m1/AdnN5LEjUX6kx5rEH7/1nEBN6Ii72pejqDVvk9anEROmPDiPw10tpFg== + +"@rspack/binding-wasm32-wasi@1.7.11": + version "1.7.11" + resolved "https://registry.yarnpkg.com/@rspack/binding-wasm32-wasi/-/binding-wasm32-wasi-1.7.11.tgz#c90235032fb14de50baf535592069923c1308f4e" + integrity sha512-OtrmnPUVJMxjNa3eDMfHyPdtlLRmmp/aIm0fQHlAOATbZvlGm12q7rhPW5BXTu1yh+1rQ1/uqvz+SzKEZXuJaQ== dependencies: "@napi-rs/wasm-runtime" "1.0.7" -"@rspack/binding-win32-arm64-msvc@1.7.10": - version "1.7.10" - resolved "https://registry.yarnpkg.com/@rspack/binding-win32-arm64-msvc/-/binding-win32-arm64-msvc-1.7.10.tgz#924a89455a4210fa5e6d404820d944e0838c9a72" - integrity sha512-FaQGSCXH89nMOYW0bVp0bKQDQbrOEFFm7yedla7g6mkWlFVQo5UyBxid5wJUCqGJBtJepRxeRfByWiaI5nVGvg== - -"@rspack/binding-win32-ia32-msvc@1.7.10": - version "1.7.10" - resolved "https://registry.yarnpkg.com/@rspack/binding-win32-ia32-msvc/-/binding-win32-ia32-msvc-1.7.10.tgz#26d2ca0f0719d164bb563a09a68be5290b56ca18" - integrity sha512-/66TNLOeM4R5dHhRWRVbMTgWghgxz+32ym0c/zGGXQRoMbz7210EoL40ALUgdBdeeREO8LoV+Mn7v8/QZCwHzw== - -"@rspack/binding-win32-x64-msvc@1.7.10": - version "1.7.10" - resolved "https://registry.yarnpkg.com/@rspack/binding-win32-x64-msvc/-/binding-win32-x64-msvc-1.7.10.tgz#98ed751af1f500f28d33b04201e457c4727d8b3c" - integrity sha512-SUa3v1W7PGFCy6AHRmDsm43/tkfaZFi1TN2oIk5aCdT9T51baDVBjAbehRDu9xFbK4piL3k7uqIVSIrKgVqk1g== - -"@rspack/binding@1.7.10": - version "1.7.10" - resolved "https://registry.yarnpkg.com/@rspack/binding/-/binding-1.7.10.tgz#fd20bafaa48541d803bbcba9cac5a680c63c0671" - integrity sha512-j+DPEaSJLRgasxXNpYQpvC7wUkQF5WoWPiTfm4fLczwlAmYwGSVkJiyWDrOlvVPiGGYiXIaXEjVWTw6fT6/vnA== +"@rspack/binding-win32-arm64-msvc@1.7.11": + version "1.7.11" + resolved "https://registry.yarnpkg.com/@rspack/binding-win32-arm64-msvc/-/binding-win32-arm64-msvc-1.7.11.tgz#0afcfde6a77cdf6fa6a85de4f8a39b94a593aab2" + integrity sha512-lObFW6e5lCWNgTBNwT//yiEDbsxm9QG4BYUojqeXxothuzJ/L6ibXz6+gLMvbOvLGV3nKgkXmx8GvT9WDKR0mA== + +"@rspack/binding-win32-ia32-msvc@1.7.11": + version "1.7.11" + resolved "https://registry.yarnpkg.com/@rspack/binding-win32-ia32-msvc/-/binding-win32-ia32-msvc-1.7.11.tgz#46606834538e84cd0f95f19089695ab122d69586" + integrity sha512-0pYGnZd8PPqNR68zQ8skamqNAXEA1sUfXuAdYcknIIRq2wsbiwFzIc0Pov1cIfHYab37G7sSIPBiOUdOWF5Ivw== + +"@rspack/binding-win32-x64-msvc@1.7.11": + version "1.7.11" + resolved "https://registry.yarnpkg.com/@rspack/binding-win32-x64-msvc/-/binding-win32-x64-msvc-1.7.11.tgz#e486a33fc1227ec9cbd70439ef1b32ead1faec68" + integrity sha512-EeQXayoQk/uBkI3pdoXfQBXNIUrADq56L3s/DFyM2pJeUDrWmhfIw2UFIGkYPTMSCo8F2JcdcGM32FGJrSnU0Q== + +"@rspack/binding@1.7.11": + version "1.7.11" + resolved "https://registry.yarnpkg.com/@rspack/binding/-/binding-1.7.11.tgz#30f3e87242d9dcb3744edc22752cf24a9ceb4d61" + integrity sha512-2MGdy2s2HimsDT444Bp5XnALzNRxuBNc7y0JzyuqKbHBywd4x2NeXyhWXXoxufaCFu5PBc9Qq9jyfjW2Aeh06Q== optionalDependencies: - "@rspack/binding-darwin-arm64" "1.7.10" - "@rspack/binding-darwin-x64" "1.7.10" - "@rspack/binding-linux-arm64-gnu" "1.7.10" - "@rspack/binding-linux-arm64-musl" "1.7.10" - "@rspack/binding-linux-x64-gnu" "1.7.10" - "@rspack/binding-linux-x64-musl" "1.7.10" - "@rspack/binding-wasm32-wasi" "1.7.10" - "@rspack/binding-win32-arm64-msvc" "1.7.10" - "@rspack/binding-win32-ia32-msvc" "1.7.10" - "@rspack/binding-win32-x64-msvc" "1.7.10" - -"@rspack/core@^1.5.0": - version "1.7.10" - resolved "https://registry.yarnpkg.com/@rspack/core/-/core-1.7.10.tgz#cb86011a730176e9067276af9688ce496af80216" - integrity sha512-dO7J0aHSa9Fg2kGT0+ZsM500lMdlNIyCHavIaz7dTDn6KXvFz1qbWQ/48x3OlNFw1mA0jxAjjw9e7h3sWQZUNg== + "@rspack/binding-darwin-arm64" "1.7.11" + "@rspack/binding-darwin-x64" "1.7.11" + "@rspack/binding-linux-arm64-gnu" "1.7.11" + "@rspack/binding-linux-arm64-musl" "1.7.11" + "@rspack/binding-linux-x64-gnu" "1.7.11" + "@rspack/binding-linux-x64-musl" "1.7.11" + "@rspack/binding-wasm32-wasi" "1.7.11" + "@rspack/binding-win32-arm64-msvc" "1.7.11" + "@rspack/binding-win32-ia32-msvc" "1.7.11" + "@rspack/binding-win32-x64-msvc" "1.7.11" + +"@rspack/core@^1.7.10": + version "1.7.11" + resolved "https://registry.yarnpkg.com/@rspack/core/-/core-1.7.11.tgz#8d7d77db3b71332afd22a9c90904fe18a6832e2c" + integrity sha512-rsD9b+Khmot5DwCMiB3cqTQo53ioPG3M/A7BySu8+0+RS7GCxKm+Z+mtsjtG/vsu4Tn2tcqCdZtA3pgLoJB+ew== dependencies: "@module-federation/runtime-tools" "0.22.0" - "@rspack/binding" "1.7.10" + "@rspack/binding" "1.7.11" "@rspack/lite-tapable" "1.1.0" "@rspack/lite-tapable@1.1.0": @@ -3598,10 +3498,10 @@ resolved "https://registry.npmjs.org/@types/google.maps/-/google.maps-3.58.1.tgz" integrity sha512-X9QTSvGJ0nCfMzYOnaVs/k6/4L+7F5uCS+4iUmkLEls6J9S/Phv+m/i3mDeyc49ZBgwab3EFO1HEoBY7k98EGQ== -"@types/gtag.js@^0.0.12": - version "0.0.12" - resolved "https://registry.npmjs.org/@types/gtag.js/-/gtag.js-0.0.12.tgz" - integrity sha512-YQV9bUsemkzG81Ea295/nF/5GijnD2Af7QhEofh7xu+kvCN6RdodgNwwGWXB5GMI3NoyvQo0odNctoH/qLMIpg== +"@types/gtag.js@^0.0.20": + version "0.0.20" + resolved "https://registry.yarnpkg.com/@types/gtag.js/-/gtag.js-0.0.20.tgz#e47edabb4ed5ecac90a079275958e6c929d7c08a" + integrity sha512-wwAbk3SA2QeU67unN7zPxjEHmPmlXwZXZvQEpbEUQuMCRGgKyE1m6XDuTUA9b6pCGb/GqJmdfMOY5LuDjJSbbg== "@types/hast@^3.0.0": version "3.0.4" @@ -4190,13 +4090,6 @@ ansi-align@^3.0.1: dependencies: string-width "^4.1.0" -ansi-escapes@^4.3.2: - version "4.3.2" - resolved "https://registry.npmjs.org/ansi-escapes/-/ansi-escapes-4.3.2.tgz" - integrity sha512-gKXj5ALrKWQLsYG9jlTRmR/xKluxHV+Z9QEwNIgCfM1/uwPMCuzVVnh5mwTd+OuBZcwSIMbqssNWRm1lE51QaQ== - dependencies: - type-fest "^0.21.3" - ansi-html-community@^0.0.8: version "0.0.8" resolved "https://registry.npmjs.org/ansi-html-community/-/ansi-html-community-0.0.8.tgz" @@ -4231,6 +4124,11 @@ ansi-styles@^6.1.0: resolved "https://registry.yarnpkg.com/ansi-styles/-/ansi-styles-6.2.3.tgz#c044d5dcc521a076413472597a1acb1f103c4041" integrity sha512-4Dj6M28JB+oAH8kFkTLUo+a2jwOFkuqb3yucU0CANcRRUbxS0cP0nZYCGjcc3BNXwRIsUVmDGgzawme7zvJHvg== +ansis@^3.2.0: + version "3.17.0" + resolved "https://registry.yarnpkg.com/ansis/-/ansis-3.17.0.tgz#fa8d9c2a93fe7d1177e0c17f9eeb562a58a832d7" + integrity sha512-0qWUglt9JEqLFr3w1I1pbrChn1grhaiAR2ocX1PP/flRmxgtwTzPFFFnfIlD6aMOLQZgSuCRlidD70lvx8yhzg== + anymatch@~3.1.2: version "3.1.3" resolved "https://registry.npmjs.org/anymatch/-/anymatch-3.1.3.tgz" @@ -5292,6 +5190,11 @@ cookie@~0.7.1: resolved "https://registry.yarnpkg.com/cookie/-/cookie-0.7.2.tgz#556369c472a2ba910f2979891b526b3436237ed7" integrity sha512-yki5XnKuf750l50uGTllt6kKILY4nQ1eNIQatoXEByZ5dWgnKqbnqmTrBE5B4N7lrMJKQ2ytWMiTO2o0v6Ew/w== +copy-text-to-clipboard@^3.2.0: + version "3.2.2" + resolved "https://registry.yarnpkg.com/copy-text-to-clipboard/-/copy-text-to-clipboard-3.2.2.tgz#99bc79db3f2d355ec33a08d573aff6804491ddb9" + integrity sha512-T6SqyLd1iLuqPA90J5N4cTalrtovCySh58iiZDGJ6FGznbclKh4UI+FGacQSgFzwKG77W7XT5gwbVEbd9cIH1A== + copy-webpack-plugin@^11.0.0: version "11.0.0" resolved "https://registry.npmjs.org/copy-webpack-plugin/-/copy-webpack-plugin-11.0.0.tgz" @@ -5311,11 +5214,6 @@ core-js-compat@^3.43.0, core-js-compat@^3.48.0: dependencies: browserslist "^4.28.1" -core-js-pure@^3.48.0: - version "3.49.0" - resolved "https://registry.yarnpkg.com/core-js-pure/-/core-js-pure-3.49.0.tgz#ff8436b7251a3832f5fdbbe3e10f7f2e58e51fb1" - integrity sha512-XM4RFka59xATyJv/cS3O3Kml72hQXUeGRuuTmMYFxwzc9/7C8OYTaIR/Ji+Yt8DXzsFLNhat15cE/JP15HrCgw== - core-js@^2.4.0: version "2.6.12" resolved "https://registry.npmjs.org/core-js/-/core-js-2.6.12.tgz" @@ -6592,7 +6490,7 @@ events@^3.2.0: resolved "https://registry.npmjs.org/events/-/events-3.3.0.tgz" integrity sha512-mQw+2fkQbALzQ7V0MY0IqdnXNOeTtP4r0lN9z7AAawCXgqea7bDii20AYrIBrFd/Hx0M2Ocz6S111CaFkUcb0Q== -execa@5.1.1, execa@^5.1.1: +execa@^5.1.1: version "5.1.1" resolved "https://registry.npmjs.org/execa/-/execa-5.1.1.tgz" integrity sha512-8uSpZZocAZRBAPIEINJj3Lo9HyGitllczc27Eh5YYojjMFMn8yHMDMaUHE2Jqfq05D/wucwI4JGURyXt1vchyg== @@ -6737,13 +6635,6 @@ feed@^4.2.2: dependencies: xml-js "^1.6.11" -figures@^3.2.0: - version "3.2.0" - resolved "https://registry.npmjs.org/figures/-/figures-3.2.0.tgz" - integrity sha512-yaduQFRKLXYOGgEn6AZau90j3ggSOyiqXU0F9JZfeXYhNa+Jk4X+s45A2zg5jns87GAFa34BBm2kXw4XpNcbdg== - dependencies: - escape-string-regexp "^1.0.5" - file-entry-cache@^8.0.0: version "8.0.0" resolved "https://registry.yarnpkg.com/file-entry-cache/-/file-entry-cache-8.0.0.tgz#7787bddcf1131bffb92636c69457bbc0edd6d81f" @@ -8806,13 +8697,6 @@ markdown-extensions@^2.0.0: resolved "https://registry.npmjs.org/markdown-extensions/-/markdown-extensions-2.0.0.tgz" integrity sha512-o5vL7aDWatOTX8LzaS1WMoaoxIiLRQJuIKKe2wAw6IeULDHaqbiqiggmx+pKvZDb1Sj+pE46Sn1T7lCqfFtg1Q== -markdown-table@^2.0.0: - version "2.0.0" - resolved "https://registry.npmjs.org/markdown-table/-/markdown-table-2.0.0.tgz" - integrity sha512-Ezda85ToJUBhM6WGaG6veasyym+Tbs3cMAw/ZhOPqXiYsr0jgocBV3j3nx+4lk47plLlIqjwuTm/ywVI+zjJ/A== - dependencies: - repeat-string "^1.0.0" - markdown-table@^3.0.0: version "3.0.4" resolved "https://registry.npmjs.org/markdown-table/-/markdown-table-3.0.4.tgz" @@ -9637,14 +9521,7 @@ minimalistic-assert@^1.0.0: resolved "https://registry.npmjs.org/minimalistic-assert/-/minimalistic-assert-1.0.1.tgz" integrity sha512-UtJcAD4yEaGtjPezWuO9wC4nwUnVH/8/Im3yEHQP4b67cXlD/Qr9hdITCU1xDbSEXg2XKNaP8jsReV7vQd00/A== -minimatch@3.1.2: - version "3.1.2" - resolved "https://registry.npmjs.org/minimatch/-/minimatch-3.1.2.tgz" - integrity sha512-J7p63hRiAjw1NDEww1W7i37+ByIrOWO5XQQAzZ3VOcL0PNybwpfmV/N05zFAzwQ9USyEcX6t3UO+K5aqBQOIHw== - dependencies: - brace-expansion "^1.1.7" - -minimatch@^3.1.1, minimatch@^3.1.2, minimatch@^3.1.5: +minimatch@3.1.5, minimatch@^3.1.1, minimatch@^3.1.2, minimatch@^3.1.5: version "3.1.5" resolved "https://registry.yarnpkg.com/minimatch/-/minimatch-3.1.5.tgz#580c88f8d5445f2bd6aa8f3cadefa0de79fbd69e" integrity sha512-VgjWUsnnT6n+NUk6eZq77zeFdpW2LWDzP6zFGrCbHXiYNul5Dzqk2HHQ5uFH2DNW5Xbp8+jVzaeNt94ssEEl4w== @@ -11332,10 +11209,10 @@ react-json-view-lite@^2.3.0: resolved "https://registry.yarnpkg.com/react-json-view-lite/-/react-json-view-lite-2.5.0.tgz#c7ff011c7cc80e9900abc7aa4916c6a5c6d6c1c6" integrity sha512-tk7o7QG9oYyELWHL8xiMQ8x4WzjCzbWNyig3uexmkLb54r8jO0yH3WCWx8UZS0c49eSA4QUmG5caiRJ8fAn58g== -react-loadable-ssr-addon-v5-slorber@^1.0.1: - version "1.0.1" - resolved "https://registry.npmjs.org/react-loadable-ssr-addon-v5-slorber/-/react-loadable-ssr-addon-v5-slorber-1.0.1.tgz" - integrity sha512-lq3Lyw1lGku8zUEJPDxsNm1AfYHBrO9Y1+olAYwpUJ2IGFBskM0DMKok97A6LWUpHm+o7IvQBOWu9MLenp9Z+A== +react-loadable-ssr-addon-v5-slorber@^1.0.3: + version "1.0.3" + resolved "https://registry.yarnpkg.com/react-loadable-ssr-addon-v5-slorber/-/react-loadable-ssr-addon-v5-slorber-1.0.3.tgz#bb3791bf481222c63a5bc6b96ee23f68cb5614b9" + integrity sha512-GXfh9VLwB5ERaCsU6RULh7tkemeX15aNh6wuMEBtfdyMa7fFG8TXrhXlx1SoEK2Ty/l6XIkzzYIQmyaWW3JgdQ== dependencies: "@babel/runtime" "^7.10.3" @@ -11738,7 +11615,7 @@ renderkid@^3.0.0: lodash "^4.17.21" strip-ansi "^6.0.1" -repeat-string@^1.0.0, repeat-string@^1.5.4: +repeat-string@^1.5.4: version "1.6.1" resolved "https://registry.npmjs.org/repeat-string/-/repeat-string-1.6.1.tgz" integrity sha512-PV0dzCYDNfRi1jCDbJzpW7jNNDRuCOG/jI5ctQcGKt/clZD+YcPS3yIlWuTJMmESC8aevCFmWJy5wjAFgNqN6w== @@ -12040,15 +11917,15 @@ serialize-javascript@^6.0.0, serialize-javascript@^6.0.1: dependencies: randombytes "^2.1.0" -serve-handler@^6.1.6: - version "6.1.6" - resolved "https://registry.npmjs.org/serve-handler/-/serve-handler-6.1.6.tgz" - integrity sha512-x5RL9Y2p5+Sh3D38Fh9i/iQ5ZK+e4xuXRd/pGbM4D13tgo/MGwbttUk8emytcr1YYzBYs+apnUngBDFYfpjPuQ== +serve-handler@^6.1.7: + version "6.1.7" + resolved "https://registry.yarnpkg.com/serve-handler/-/serve-handler-6.1.7.tgz#e9bb864e87ee71e8dab874cde44d146b77e3fb78" + integrity sha512-CinAq1xWb0vR3twAv9evEU8cNWkXCb9kd5ePAHUKJBkOsUpR1wt/CvGdeca7vqumL1U5cSaeVQ6zZMxiJ3yWsg== dependencies: bytes "3.0.0" content-disposition "0.5.2" mime-types "2.1.18" - minimatch "3.1.2" + minimatch "3.1.5" path-is-inside "1.0.2" path-to-regexp "3.3.0" range-parser "1.2.0" @@ -12921,11 +12798,6 @@ type-check@~0.3.2: dependencies: prelude-ls "~1.1.2" -type-fest@^0.21.3: - version "0.21.3" - resolved "https://registry.npmjs.org/type-fest/-/type-fest-0.21.3.tgz" - integrity sha512-t0rzBq87m3fVcduHDUFhKmyyX+9eo6WQjZvf51Ea/M0Q7+T374Jp1aUiyUl0GKxp8M/OETVHSDvmkyPgvX+X2w== - type-fest@^0.5.0: version "0.5.2" resolved "https://registry.npmjs.org/type-fest/-/type-fest-0.5.2.tgz" @@ -13547,19 +13419,15 @@ webpack@^5.88.1, webpack@^5.95.0: watchpack "^2.5.1" webpack-sources "^3.3.4" -webpackbar@^6.0.1: - version "6.0.1" - resolved "https://registry.npmjs.org/webpackbar/-/webpackbar-6.0.1.tgz" - integrity sha512-TnErZpmuKdwWBdMoexjio3KKX6ZtoKHRVvLIU0A47R0VVBDtx3ZyOJDktgYixhoJokZTYTt1Z37OkO9pnGJa9Q== +webpackbar@^7.0.0: + version "7.0.0" + resolved "https://registry.yarnpkg.com/webpackbar/-/webpackbar-7.0.0.tgz#7228d32881af2392381b6514499ddea73cdf218a" + integrity sha512-aS9soqSO2iCHgqHoCrj4LbfGQUboDCYJPSFOAchEK+9psIjNrfSWW4Y0YEz67MKURNvMmfo0ycOg9d/+OOf9/Q== dependencies: - ansi-escapes "^4.3.2" - chalk "^4.1.2" + ansis "^3.2.0" consola "^3.2.3" - figures "^3.2.0" - markdown-table "^2.0.0" pretty-time "^1.1.0" std-env "^3.7.0" - wrap-ansi "^7.0.0" websocket-driver@>=0.5.1, websocket-driver@^0.7.4: version "0.7.4"