-
Notifications
You must be signed in to change notification settings - Fork 55
WorkflowConfig
The WorkflowConfig
struct allows for customization of workflow execution behavior within the iWF. It provides options to control various aspects of workflow management, including setting executing state ID to workflow search attributes, continue-as-new behavior, and execution optimizations.
Decides if system search attributes are used. Defaults to false
.
Determines which of the executing state IDs will be saved to workflow search attributes:
-
ENABLED_FOR_ALL
: every executing state ID is added to workflow search attributes -
ENABLED_FOR_STATES_WITH_WAIT_UNTIL
: only IDs of the executing states that do not execute right away (skipwait until
API) are added to workflow search attributes -
DISABLED
: no state IDs are added to workflow search attributes
Sets a threshold for the number of workflow operations (signals received + executed state APIs + sync update received) after which the workflow will be continued as new. This helps manage the size of workflow history and prevent unbounded growth. 0
means unlimited.
Specifies the maximum size (in bytes) of the data dump where continuing workflow is new. 0
sets it to default 1 MB.
Enables optimizations for activity executions within the workflow. When true
, Temporal's Local Activity will be used instead of regular activity. It minimizes the storage cost as the payload will not be shown in activity input. Defaults to false
.
Enables optimizations for timer executions within the workflow. Minimizes costs by limiting number of timers started.
Without optimization, a new timer is always created when receiving a REST timer request.
Example: If the first timer is 7 days, and after one day, the client requests to create another 7-day timer, then after another day, it requests another 7-day timer again, there will be 3 timers created and active.
The optimization allows for the lazy creation of timers ensuring only one timer is active at the time.
Example: In the same scenario as above, after creating the first timer, the requests to create the other two will be kept in memory and only created for the leftover time (1 day) after the first timer fired.
Visual explanation:
Defaults to false
.