Activity implementation is an implementation of an Activity interface. A single instance of the Activities implementation is shared across multiple simultaneous Activity invocations. Therefore, the Activity implementation code must be stateless.
The values passed to Activities through invocation parameters or returned through a result value are recorded in the execution history. The entire execution history is transferred from the Temporal service to Workflow workers when a Workflow state needs to recover. A large execution history can thus adversely impact the performance of your Workflow. Therefore, be mindful of the amount of data you transfer via Activity invocation parameters or return values.
Otherwise, no additional limitations exist on Activity implementations.
Accessing Activity Info
The Activity class provides static getters to access information about the Workflow that invoked it. Note that this information is stored in a thread local variable. Therefore, calls to Activity accessors succeed only in the process that invoked the Activity function.
Activity Heart Beating
Some Activities are long-running. To react to a crash quickly, use a heartbeat mechanism.
Activity::heartbeat() lets the Temporal service know that the Activity is still alive.
You can piggyback
details on an Activity heartbeat. If an Activity times out, the last value of
details is included
TimeoutFailure delivered to a Workflow. Then the Workflow can pass the details to the next Activity
invocation. This acts as a periodic checkpoint mechanism for the progress of an Activity.