.NET SDK DescribeAsync to get Workflow status
Use DescribeAsync() on a WorkflowHandle in .NET SDK to get the current status of a Workflow. If the Workflow does not exist, this call fails.
workflow fundamentals
60 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
.NET SDK get Workflow results with GetResultAsync
To get Workflow Execution results in .NET SDK, use StartWorkflowAsync() or GetWorkflowHandle() to return a Workflow handle, then use the GetResultAsync() method to await the result. Example: var handle = client.GetWorkflowHandle("my-workflow-id"); var result = await handle.GetResultAsync<string>();
Temporal Client cannot be initialized inside a Workflow
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.
.NET SDK start Workflow with ExecuteWorkflowAsync
To start a Workflow Execution in .NET SDK, use either StartWorkflowAsync() or ExecuteWorkflowAsync() methods. You must set a Workflow Id and Task Queue in the WorkflowOptions. Example: var result = await client.ExecuteWorkflowAsync((MyWorkflow wf) => wf.RunAsync(), new(id: "my-workflow-id", taskQueue: "my-task-queue"));
.NET SDK get Workflow handle by Id
To get a handle for an existing Workflow by its Id in .NET SDK, use GetWorkflowHandle(). The Workflow Id, Run Id, and Namespace together uniquely identify a Workflow Execution in the system.
Temporal Client enables communication with Temporal Service
A Temporal Client enables you to communicate with the Temporal Service and perform actions such as starting Workflow Executions, sending Signals and Queries to Workflow Executions, and getting Workflow results. A Temporal Client can also start and manage Standalone Activities directly without involving a Workflow.
Namespace definition and purpose
A Namespace is a unit of isolation within the Temporal Platform. It ensures that Workflow Executions, Task Queues, and resources are logically separated, preventing conflicts and enabling safe multi-tenant usage.
Workflow.wait_condition for blocking on messages or timeout
workflow.wait_condition() blocks until the lambda condition returns True or the timeout expires. In Entity Workflows, block on pending signals, shutdown flag, Continue-As-New suggestion, or timeout. This allows the Workflow to wake for multiple reasons.
Python SDK start_workflow for Entity Workflows
Use client.start_workflow() with a stable Workflow Id tied to the entity identifier (e.g., 'loyalty-cust-123'). If the Workflow is already running, start_workflow raises WorkflowAlreadyStartedError. Clients can use a handle to the running instance.
Entity Workflow vs Actor Model distinction
An Entity Workflow represents state and responds to interactions, functioning closer to a data cache than a process orchestrator. It holds and serves state, evaluates business rules against that state, and delegates side effects to Activities. An actor, by contrast, takes actions such as writing to databases, calling external APIs, or sending emails as part of its core behavior. In the Entity Workflow pattern, side effects are delegated to Activities while the Workflow remains a pure state container with business rules.
Entity Workflow use case: customer loyalty program
In a customer loyalty program, each customer gets their own Entity Workflow identified by their customer ID. The Workflow holds the account's points balance, tier status, and activity history in memory. When a purchase happens, a Signal adds the points. When a customer redeems at checkout, an Update validates and applies the redemption synchronously. When a mobile app needs to display the current balance, a Query reads the state without touching the database.
Why Temporal is well suited for Entity Workflows
Temporal provides several capabilities for Entity Workflows: Durable Timers allow sleeping for hours, days, or months without consuming compute resources; Message passing via Signals, Queries, and Updates provides distinct interaction patterns; Event History records every state transition in an append-only log for compliance and debugging; Continue-As-New allows Workflows to reset with fresh history while preserving current state for years of operation; Deterministic replay resumes Workflows from last known state by replaying Event History after Worker crashes with no state loss.
Workflow client interaction after Continue-As-New
After Continue-As-New, clients continue interacting with the same Workflow Id. Temporal automatically routes Signals, Queries, and Updates to the latest Run. Do not specify a Run Id when obtaining a Workflow handle, or interactions will target a stale Execution.
Python SDK @workflow.init decorator purpose
The @workflow.init decorator ensures initialization runs before any Signal or Update handler, preventing race conditions with Signal-with-Start. It initializes Workflow state that handlers will access.
Trimming processed event IDs in Entity Workflows
Keep only the most recent processed event IDs (e.g., last 1,000) to prevent unbounded growth of the state. Rely on an external store for long-term deduplication beyond the trim window.
What is an Entity Workflow
An Entity Workflow is an architectural pattern describing a Workflow that represents something persisting over time, such as a customer, device, order, or bank account. It differs from a process workflow, which has a definite end. An entity is a thing, whereas a process workflow does a thing. Entity Workflows have an indefinite lifetime and react to events as they arrive.
Three defining characteristics of Entity Workflows
Entity Workflows share three defining characteristics: they run for an indefinite duration with no known start or completion time; they react to external messages at any point in their lifecycle via Signals, Updates, and Queries; and they maintain mutable state that evolves over time in response to those messages.
Workflow-level retry loop with worker affinity recovery
Implement a for loop in the Workflow that attempts the entire activity sequence on a new Worker each time a timeout or exception occurs. Example: for attempt in range(max_worker_attempts): try: [execute activities] except Exception as e: [log warning and continue]. This allows the Workflow to recover from Worker failures by requesting a new unique queue from a different healthy Worker, rather than retrying on the failed Worker's queue.
Supported SDKs for Temporal development
Temporal provides official SDKs for the following languages: Go, Java, .NET (C#), PHP, Python, Ruby, Rust, and TypeScript. Each SDK includes quickstart documentation for local setup and running Hello World workflows.
Cloud setup documentation location
For users working with Temporal Cloud, setup guidance is provided in the Get started with Temporal Cloud documentation separate from local quickstarts.
Temporal use cases
Temporal enables developers to focus on building features that drive the business while ensuring that mission-critical processes such as order fulfillment, customer onboarding, and payment processing never fail or disappear, regardless of what goes wrong.
Temporal Platform core guarantee
Temporal is an open-source platform for building reliable applications that delivers crash-proof execution by guaranteeing that applications resume exactly where they left off after crashes, network failures, or infrastructure outages, whether that happens seconds, days, or even years later.
Datastore TLS configuration
The tls section in datastores contains: enabled (boolean), serverName (name of server hosting the data store), certFile (path to cert file), keyFile (path to key file), caFile (path to ca file), and enableHostVerification (boolean, true to verify hostname and server cert like wildcard for Cassandra cluster). Note: certFile and keyFile are optional depending on server config, but both fields must be omitted to avoid using a client certificate.
Persistence defaultStore requirement
The persistence section requires defaultStore, which is the name of the data store definition that should be used by the Temporal server.
Google Cloud Storage archival provider
The gstorage archival provider supports credentialsPath parameter for specifying path to Google Cloud credentials JSON file.
Temporal Cluster configuration file location
Temporal Cluster behavior is configured using the development.yaml file. Changing any properties in the development.yaml file requires a process restart for changes to take effect.
Top-level configuration sections in development.yaml
The development.yaml file contains the following top-level sections: global, persistence, log, clusterMetadata, services, publicClient, archival, namespaceDefaults, dcRedirectionPolicy, and dynamicConfigClient.
Persistence visibilityStore requirement
The persistence section requires visibilityStore, which is the name of the primary data store definition that should be used to set up Visibility on the Temporal Cluster.
Persistence secondaryVisibilityStore optional
The persistence section optionally includes secondaryVisibilityStore, the name of the secondary data store definition for setting up Dual Visibility on the Temporal Cluster.
Persistence numHistoryShards immutability
The numHistoryShards parameter is required and specifies the number of history shards to create when initializing the Cluster. This value is immutable and will be ignored after the first run. Ensure it is set appropriately high enough to scale with the worst case peak load for the Cluster.
Persistence datastores structure
The datastores section is required and contains named data store definitions referenced by name (e.g., default, visibility). Each definition must be either cassandra or sql.
Cassandra data store configuration
A cassandra data store definition contains: hosts (required, comma-separated Cassandra endpoints like '192.168.1.2,192.168.1.3,192.168.1.4'), port (default 9042, Cassandra port for gocql client), user (username for gocql authentication), password (password for gocql authentication), keyspace (required, Cassandra keyspace), datacenter (data center filter for Cassandra), maxConns (max connections for single TLS configuration), and tls (TLS configuration).
SQL data store configuration
A sql data store definition contains: user (username for authentication), password (password for authentication), pluginName (required, SQL database type: mysql or postgres), databaseName (required, SQL database name), connectAddr (required, remote database address like '192.168.1.2'), connectProtocol (required, protocol for connectAddr: tcp or unix), connectAttributes (optional key-value attributes for data_source_name url, with cache parameter for SQLite shared-cache mode and setup parameter to auto-initialize SQLite schema), maxConns (max connections), maxIdleConns (max idle connections), maxConnLifetime (maximum time a connection can be alive), and tls (TLS configuration).
Cluster metadata configuration
The clusterMetadata section contains local cluster information used in Multi-Cluster Replication with parameters: currentClusterName (required, name of current cluster, immutable after first run), enableGlobalNamespace (default false), replicationConsumer (determines method to consume replication tasks: kafka or rpc), failoverVersionIncrement (increment of cluster version when failover happens), masterClusterName (master cluster name, only master can register/update namespace), and clusterInformation (contains local cluster name to ClusterInformation definition, local cluster name should match currentClusterName).
Cluster information definition
Each ClusterInformation section in clusterMetadata contains: enabled (boolean, whether remote cluster is enabled for replication), initialFailoverVersion, and rpcAddress (remote service address host:port, host can be DNS name, use dns:/// prefix for round-robin between IP addresses).
Archival configuration states
Archival state parameter supports values: enabled (enables Archival, requires URI and namespaceDefaults values) and disabled (disables Archival, requires enableRead set to false and namespaceDefaults state set to disabled with no provider and URI values).
Archival configuration for history and visibility
Archival configuration applies to history and visibility data independently, each supporting: state (enabled or disabled), enableRead (true or false, allows read operations from archived Event History), and provider (filestore, gstorage, s3, or custom provider, default is filestore).
Filestore archival provider
The filestore archival provider supports fileMode and dirMode parameters for specifying permissions.
Namespace defaults archival configuration
The namespaceDefaults section optionally sets default Archival configuration for each Namespace for history and visibility data independently, each with state (enabled or disabled) and URI (default URI for the Namespace).
DC redirection policy options
The dcRedirectionPolicy section contains policy parameter with supported values: noop (no redirection, default), selected-apis-forwarding (forwarding for StartWorkflowExecution, SignalWithStartWorkflowExecution, SignalWorkflowExecution, RequestCancelWorkflowExecution, TerminateWorkflowExecution, QueryWorkflow to active Cluster), and all-apis-forwarding (forwarding for all APIs on the Namespace to active Cluster).
Dynamic config client configuration
The dynamicConfigClient section (optional) configures file-based dynamic configuration client for the Cluster with: filepath (required if specifying dynamic configuration, path where dynamic configuration YAML file is stored, relative to root directory) and pollInterval (interval between file-based client polls for dynamic configuration updates, minimum 5 seconds).
WorkflowExecutionTerminated event indicates forced termination
WorkflowExecutionTerminated event indicates that the Workflow Execution has been forcefully terminated and likely the terminate Workflow API was called. It has fields: reason (Information provided by user or client for Workflow termination), details (Additional information reported by Workflow upon termination), identity (Identifies Worker that requested termination).
RequestCancelExternalWorkflowExecutionFailed event
RequestCancelExternalWorkflowExecutionFailed event indicates that Temporal Server could not cancel the targeted Workflow, usually because target Workflow could not be found. It has fields: workflow_task_completed_event_id (Id of WorkflowTaskCompleted Event reported with), namespace (Namespace of Workflow that failed to cancel), workflow_execution (Identifies Workflow and run of Workflow Execution), initiated_event_id (Id of RequestCancelExternalWorkflowExecutionInitiated Event this failure corresponds to).
ExternalWorkflowExecutionCancelRequested event
ExternalWorkflowExecutionCancelRequested event indicates that the Temporal Server has successfully requested the cancelation of the target Workflow. It has fields: initiated_event_id (Id of RequestCancelExternalWorkflowExecutionInitiated Event that this cancelation request corresponds to), namespace (Namespace of Workflow that was requested to cancel), workflow_execution (Identifies Workflow and run of Workflow Execution).
WorkflowTaskScheduled event indicates task scheduled
WorkflowTaskScheduled event indicates that the Workflow Task has been scheduled. The SDK client should now be able to process any new history events. It has fields: task_queue (Task Queue where Workflow Task was enqueued), start_to_close_timeout (Time that Worker takes to process Task once received), attempt (Number of attempts made to complete Task).
WorkflowTaskStarted event indicates task processing begun
WorkflowTaskStarted event indicates that the Workflow Task has started. The SDK client has picked up the Workflow Task and is processing new history events. It has fields: scheduled_event_id (Id of WorkflowTaskScheduled Event this Workflow Task corresponds to), identity (Identifies Worker that started Task), request_id (Identifies Workflow Task request).
WorkflowTaskCompleted event and subsequent events
WorkflowTaskCompleted event indicates that the Workflow Task completed. It has fields: scheduled_event_id (Id of WorkflowTaskScheduled Event this Workflow Task corresponds to), started_event_id (Id of WorkflowTaskStarted Event this Task corresponds to), identity (Identity of Worker that completed Task), binary_checksum (Binary Id of Worker that completed Task). The SDK client picked up the Workflow Task, processed new history events, and may or may not ask the Temporal Server to do additional work. The following events can still occur after WorkflowTaskCompleted: ActivityTaskScheduled, TimerStarted, UpsertWorkflowSearchAttributes, MarkerRecorded, StartChildWorkflowExecutionInitiated, RequestCancelExternalWorkflowExecutionInitiated, SignalExternalWorkflowExecutionInitiated, WorkflowExecutionCompleted, WorkflowExecutionFailed, WorkflowExecutionCanceled, WorkflowExecutionContinuedAsNew.
WorkflowExecutionCanceled event indicates cancelation confirmed
WorkflowExecutionCanceled event indicates that the client has confirmed the cancelation request and the Workflow Execution has been canceled. It has fields: workflow_task_completed_event_id (Id of WorkflowTaskCompleted Event reported with), details (Additional information reported by Workflow upon cancelation).
WorkflowExecutionContinuedAsNew event indicates continuation
WorkflowExecutionContinuedAsNew event indicates that the Workflow has successfully completed, and a new Workflow has been started within the same transaction. This Event type contains last Workflow Execution results as well as new Workflow Execution inputs. It has fields: new_execution_run_id (Run Id of new Workflow started by Continue-As-New Event), workflow_type (Name/type of Workflow started by Event), task_queue (Task Queue where Workflow Task was enqueued), input (Deserialized to provide arguments to Workflow), workflow_run_timeout (Timeout of single Workflow run), workflow_task_timeout (Timeout of single Workflow Task), workflow_task_completed_event_id (Id of WorkflowTaskCompleted Event command reported with), backoff_start_interval (Amount of time to delay beginning of ContinuedAsNew Workflow), initiator (Allows Workflow to continue as new execution), last_completion_result (Information passed by previously completed Task to ongoing execution), header (Information passed by sender of Signal copied into Workflow Task), memo (Non-indexed information to show in Workflow), search_attributes (Data for setting up Workflow's Search Attributes).
MarkerRecorded event and SDK local activities
MarkerRecorded event is transparent to the Temporal Server. The Server will only store it and will not try to understand it. The SDK client may use it for local activities or side effects. It has fields: marker_name (Identifies various markers), details (Serialized information recorded in marker), workflow_task_completed_event_id (Id of WorkflowTaskCompleted Event reported with), header (Information passed by sender of Signal copied into marker), failure (Serialized result of Workflow failure).
UpsertWorkflowSearchAttributes event
UpsertWorkflowSearchAttributes event indicates that the Workflow Search Attributes should be updated and synchronized with visibility store. It has fields: workflow_task_completed_event_id (WorkflowTaskCompleted Event reported Event with this Id), search_attributes (Data for setting up Workflow's Search Attributes).
WorkflowExecutionStarted event first in history
WorkflowExecutionStarted is always the first event in a Workflow Execution Event History. It indicates that the Temporal Service received a request to spawn the Workflow Execution.
WorkflowExecutionStarted event fields
WorkflowExecutionStarted event contains the following fields: workflow_type (Name of Workflow initiated), parent_workflow_namespace (Namespace of Parent Workflow Execution if applicable), parent_workflow_execution (Identifies parent Workflow and execution run), parent_initiated_event_id (Id of StartWorkflowExecutionInitiated Event), task_queue (Task Queue where Workflow Task was enqueued), input (Deserialized to provide arguments to Workflow), workflow_execution_timeout (Total timeout for Workflow Execution including retries and continue-as-new), workflow_run_timeout (Timeout of single Workflow run), workflow_task_timeout (Timeout of single Workflow Task), continued_execution_run_id (Run Id of previous Workflow which continued-as-new, retried or was executed by Cron), initiator (Allows Workflow to continue as new Workflow Execution), continued_failure (Serialized result of failure), last_completion_result (Information from previously completed Task if applicable), original_execution_run_id (Run Id of original Workflow started), identity (Id of Client or parent Workflow Worker that requested start), first_execution_run_id (First Run Id along chain of Continue-As-New Runs and Reset), retry_policy (Amount of retries as determined by service's dynamic configuration), attempt (Number of attempts made to complete Task), workflow_execution_expiration_time (Absolute time at which Workflow Execution will time out), cron_schedule (Workflow's Cron Schedule if applicable), first_workflow_task_backoff (Amount of time between when Workflow iteration scheduled and when it should run next, applies to Cron Scheduling), memo (Non-indexed information to show in Workflow), search_attributes (Data for setting up Workflow's Search Attributes), prev_auto_reset_points, header (Information passed by sender of Signal copied into Workflow Task), completion_callbacks (Completion callbacks attached when workflow was started).
WorkflowExecutionCompleted event indicates successful completion
WorkflowExecutionCompleted event indicates that the Workflow Execution has successfully completed and contains Workflow Execution results. It has fields: result (Serialized result of completed Workflow), workflow_task_completed_event_id (Id of WorkflowTaskCompleted Event reported with), new_execution_run_id (Run Id of new Workflow Execution started as result of Cron Schedule).
WorkflowExecutionFailed event indicates unsuccessful completion
WorkflowExecutionFailed event indicates that the Workflow Execution has unsuccessfully completed and contains the Workflow Execution error. It has fields: failure (Serialized result of Workflow failure), retry_state (Reason provided for whether Task should or shouldn't be retried), workflow_task_completed_event_id (Run Id of WorkflowTaskCompleted Event reported with), new_execution_run_id (Run Id of new Workflow started by Cron or Retry).
InterruptOn server option behavior
InterruptOn provides a channel that interrupts the server on signal from that channel. If not passed, server.Start() is never blocked and you must call server.Stop() elsewhere. If passed nil, server.Start() blocks forever until the process is killed. If passed temporal.InterruptCh(), server.Start() blocks until Ctrl+C is used, then gracefully shuts down. If passed a custom channel, server.Start() blocks until a signal is sent to that channel.
ForServices server option
ForServices sets the list of all valid temporal services. The default list can be used from the go.temporal.io/server/temporal package.
WithConfigLoader server option
WithConfigLoader loads a custom configuration from a file, accepting parameters for the config directory, environment, and zone.
WithConfig server option
WithConfig passes a configuration object to the Temporal Server at startup. The server automatically searches for a configuration file at ./config/development.yaml when starting. Use this option to specify a custom configuration instead of the default location.
Running Temporal Server as Go application
The Temporal Server can be run as a Go application by including the server package go.temporal.io/server/temporal and using it to create and start a server. Create a server with temporal.NewServer(), then call Start() on the returned server instance. NewServer() accepts functions as parameters, each returning a ServerOption that is applied to the instance.