activities & execution guarantees

18 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Minimize data transfer through Activity parameters and return values

Be mindful of the amount of data transferred through Activity invocation parameters or return values to avoid adversely impacting Workflow performance due to large Execution histories.

ExecuteActivityAsync executes a Standalone Activity and waits for result

Use client.ExecuteActivityAsync() to execute a Standalone Activity and wait for the result. This method durably enqueues your Standalone Activity in the Temporal Server, waits for it to be executed on your Worker, and then returns the result. Call this from your application code, not from inside a Workflow Definition.

ExecuteActivityAsync accepts lambda or string Activity type name

ExecuteActivityAsync accepts the Activity in two ways: as a lambda expression using () => MyActivities.MethodName() for type-safety, or as a string Activity type name with generic type parameter and argument array.

StartActivityOptions required fields

StartActivityOptions requires Id, TaskQueue, and at least one of ScheduleToCloseTimeout or StartToCloseTimeout. These are the mandatory parameters for starting a Standalone Activity.

StartActivityAsync starts Standalone Activity without waiting for result

Use client.StartActivityAsync() to start a Standalone Activity and get a handle without waiting for the result. This returns an activity handle that can be used later to retrieve the result.

GetResultAsync waits for Standalone Activity execution result

Call await handle.GetResultAsync() to wait for a Standalone Activity to be executed and return the result. Under the hood, calling client.ExecuteActivityAsync() is the same as calling client.StartActivityAsync() and then calling await handle.GetResultAsync().

ExecuteActivity returns ActivityHandle

client.ExecuteActivity() returns an ActivityHandle that can be used to get the result, describe, cancel, or terminate the Activity.

StartActivityOptions required fields

client.StartActivityOptions requires ID, TaskQueue, and at least one of ScheduleToCloseTimeout or StartToCloseTimeout.

ActivityHandle.Get() blocks until Activity completes

Use ActivityHandle.Get() to block until the Activity completes and retrieve its result. This is analogous to calling Get() on a WorkflowRun. If the Activity completed successfully, the result is deserialized into the provided pointer. If the Activity failed, the failure is returned as an error.

GetActivityHandle requires ActivityID and RunID

Use client.GetActivityHandle() to create a handle to a previously started Standalone Activity. Both ActivityID and RunID are required parameters.

ListActivities and CountActivities return only Standalone Activities

client.ListActivities() and client.CountActivities() APIs return only Standalone Activity Executions. Activities running inside Workflows are not included.

Execute Activity by function reference or string type name

When calling client.ExecuteActivity(), the Activity can be passed as either a function reference (e.g., helloworld.Activity) or as a string Activity type name (e.g., "Activity").

Standalone Activities example code in Go

Example starter program demonstrating Standalone Activities execution: ```go package main import ( "context" "github.com/temporalio/samples-go/standalone-activity/helloworld" "go.temporal.io/sdk/client" "go.temporal.io/sdk/contrib/envconfig" "log" "time" ) func main() { c, err := client.Dial(envconfig.MustLoadDefaultClientOptions()) if err != nil { log.Fatalln("Unable to create client", err) } defer c.Close() activityOptions := client.StartActivityOptions{ ID: "standalone_activity_helloworld_ActivityID", TaskQueue: "standalone-activity-helloworld", ScheduleToCloseTimeout: 10 * time.Second, } handle, err := c.ExecuteActivity(context.Background(), activityOptions, helloworld.Activity, "Temporal") if err != nil { log.Fatalln("Unable to execute activity", err) } log.Println("Started standalone activity", "ActivityID", handle.GetID(), "RunID", handle.GetRunID()) var result string err = handle.Get(context.Background(), &result) if err != nil { log.Fatalln("Unable get standalone activity result", err) } log.Println("Activity result:", result) resp, err := c.ListActivities(context.Background(), client.ListActivitiesOptions{ Query: "TaskQueue = 'standalone-activity-helloworld'", }) if err != nil { log.Fatalln("Unable to list activities", err) } log.Println("ListActivity results") for info, err := range resp.Results { if err != nil { log.Fatalln("Error iterating activities", err) } log.Printf("\tActivityID: %s, Type: %s, Status: %v\n", info.ActivityID, info.ActivityType, info.Status) } resp1, err := c.CountActivities(context.Background(), client.CountActivitiesOptions{ Query: "TaskQueue = 'standalone-activity-helloworld'", }) if err != nil { log.Fatalln("Unable to count activities", err) } log.Println("Total activities:", resp1.Count) } ``` This example shows how to execute a Standalone Activity, get its result, list activities, and count activities.

Activity failure and automatic retry behavior

If an Activity fails, such as when an API goes down, Temporal will automatically retry the Activity with one second between intervals, as the configurations have defined, an infinite number of times until the Activity succeeds or is canceled.

Activity routing in Pinned Workflows

Activities generally start on the Worker Deployment Version of their Workflow. For Pinned Workflows, an Activity starts on the pinned version.

Activity routing in Auto-Upgrade Workflows

For Auto-Upgrade Workflows, an Activity starts on the Target Worker Deployment Version of the Workflow. In this case, Workflow Execution moves to its Target Version immediately before starting the Activity if the Target Version is different from the last used Version. The Target Worker Deployment Version of a Workflow is the Current or Ramping Version of the Workflow's Task Queue, depending on the Ramp Percentage and Workflow ID.

Independent Activities definition and behavior

Independent Activities are specific to Worker Versioning. They start on the Current or Ramping Version of their own Task Queue independently from their Workflow. For a Pinned Workflow, Independent Activities are Activities that start on a Task Queue that's not a member of the calling Workflow's Pinned Worker Deployment Version. For an Auto-Upgrade Workflow, Independent Activities are Activities that start on a Task Queue that's not a member of the calling Workflow's Target Worker Deployment Version.

Independent Activity deployment scenarios

Independent Activities can run in several different ways: the Activity Task Queue is running in a separate Worker Deployment that only has the Independent Activity, the Independent Activity is in an unversioned Task Queue, or the Independent Activity is in a separate Worker Deployment that has its own Workflows but other Workflows reuse the Activity from other Worker Deployments.

Give your agent this brain