Skip to main content

About state management

In Taskurai, all Tasks and Steps are persisted to guarantee a durable and stateful operation. However, tasks and steps are stored in the central database and are subject to size limits depending on the subscription plan. They are meant to maintain initialization and configuration data and return values. Large initialization and return data should be stored in a state store and referenced in the tasks and steps.

State stores can contain any kind of data that the commands depend on, suited for long-running applications that need to maintain state. State is stored in key-value stores.

State Stores​

The default state stores in Taskurai consist of a database and a storage container. State stores can contain serializable text data or any binary content.

State stores can be configured in the Taskurai YAML configuration and deployed using the Taskurai CLI.

info

State stores are deployed in the Taskurai Hub, installed in your own subscription. Extra Azure costs apply on database and storage, bandwidth, etc. usage.

State store types​

A state store can be configured to either share or have dedicated database and storage accounts, providing more throughput and avoiding noisy neighbor issues. You can choose between a standard or premium storage account, depending on your needs, such as storing large files with optimal performance and lower latency.

Depending on the Taskurai Plan, it is possible to define multiple dedicated state stores, either sharing the same resources or being set up with dedicated resources.

Features​

State stores support advanced features with an easy to use API:

  • Easy to setup and update using the Taskurai CLI.
  • Supports serializable types and blobs in the same state store.
  • Concurrency and consistency control.
  • Transactions and bulk operations.
  • Listing and filtering state items.
  • Automatic cleanup of state (and blobs) using configurable time-to-live (TTL).

Limitations​

In Taskurai, state stores are not meant to act as long-term storage for business critical data or to replace any kind of permanent database or storage solution. Please store business critical data in dedicated databases and storage solutions where you have control over redundancy, backup, etc.

Kinds of state entries​

The key/value state stores can be used in two distinct ways:

  • Generic state: State entries have generic state id's, can be linked to tasks, but have a different lifecycle to a task (eg. configuration file, shopping cart, ...).
  • Task related state: Storing state, directly related to tasks, like task initialization, intermediate and final state (eg. large export file, intermediate split files, final result file). This state can follow the task lifecycle and can be configured to cleanup after task completion (TTL).

State naming convention​

Default naming convention​

The default naming convention for state entries is:

state::<stateId>

When running in isolation mode, the isolation key is added:

isolation::<isolationKey>::state::<stateId>

When state is linked with a TaskConfig or TaskResponse, the state naming convention is like this:

task::<taskId>::state::<stateId>

When running in isolation mode, the isolation key is added:

isolation::<isolationKey>::task::<taskId>::state::<stateId>

State id​

A state id can be any alphanumeric character (case insensitive). It is possible to use the :: separator to bring hierarchy in the key.

Examples:

  • order::<orderId>
  • customer::<customerId>::addresses::delivery
tip

Separators can be useful when listing state by filtering on partial keys.