Standalone Activities can use Temporal Client directly
For Standalone Activities, a Temporal Client can start and manage Standalone Activities directly, without involving a Workflow.
activities: core concepts
7 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
ActivityTaskStarted event not written to history until terminal event
ActivityTaskStarted indicates that an Activity Task Execution was started. The SDK Worker picked up the Activity Task and started processing the Activity invocation. ActivityTaskStarted is generated by the server when the Task is dispatched to the Worker, not when the Worker starts executing the Task. However, this Event is not written to History until the terminal Event (like ActivityTaskCompleted or ActivityTaskFailed) occurs.
ActivityTaskStarted event fields
ActivityTaskStarted contains: scheduled_event_id (Id of ActivityTaskScheduled Event), identity (identifies Worker that started Task), request_id (identifies Activity Task request), attempt (number of attempts to complete Task), last_failure (details from most recent failure Event; only assigned if Task previously failed and been retried).
ActivityTaskScheduled event structure and timeout configuration
ActivityTaskScheduled indicates that an Activity Task was scheduled. The SDK client should pick up this Activity Task and execute. It contains: activity_id (identifier assigned to Activity by Worker or user), activity_type (type of Activity scheduled), namespace (namespace of Workflow containing Activity), task_queue (Task Queue where Activity Task was enqueued), header (information from Signal sender copied into Workflow Task), input (deserialized to provide Workflow function arguments), schedule_to_close_timeout (time caller waits for Activity completion; limits retry time for Activity), schedule_to_start_timeout (limits time Activity Task can stay in Task Queue; cannot be retried), start_to_close_timeout (maximum execution time after Worker picks up Activity; retryable), heartbeat_timeout (maximum time allowed between successful Worker heartbeats), workflow_task_completed_event_id (Id of WorkflowTaskCompleted), retry_policy (amount of retries per service dynamic configuration; retries happen until schedule_to_close_timeout is reached).
ActivityTaskCancelRequested event
ActivityTaskCancelRequested indicates that a request to cancel the Activity has occurred. It contains: scheduled_event_id (Id of ActivityTaskScheduled Event), workflow_task_completed_event_id (Id of WorkflowTaskCompleted that reported Event).
ActivityTaskCanceled event
ActivityTaskCanceled indicates that the Activity has been canceled. It contains: details (additional information reported by Activity upon confirming cancelation), latest_cancel_requested_event_id (Id of most recent ActivityTaskCancelRequested Event), scheduled_event_id (Id of ActivityTaskScheduled Event), started_event_id (Id of ActivityTaskStarted Event), identity (identifies Worker that requested cancelation).
ActivityTaskCompleted event
ActivityTaskCompleted indicates that the Activity Task has completed. The SDK client has picked up and successfully completed the Activity Task. It contains: result (serialized result of completed Activity), scheduled_event_id (Id of ActivityTaskScheduled Event), started_event_id (Id of ActivityTaskStarted Event), identity (identity of Worker that completed Task).